Transaction lifecycle management

ABSTRACT

A transaction management platform is provided that is configured to perform end-to-end tracking of messages in a medical network. Message tracking information is used to provide a graphical diagram to represent flow of messages within the medical network. Graphical properties of the diagram correspond to different properties of the messages.

RELATED APPLICATIONS

The present application is a continuation and claims the benefit ofpriority of U.S. Non-Provisional application Ser. No. 15/976,641, filedMay 10, 2018, which is a continuation and claims the benefit of priorityof U.S. Non-Provisional application Ser. No. 15/670,932, filed on Aug.7, 2017, and issued as U.S. Pat. No. 9,973,465, which is acontinuation-in-part and claims the benefit of priority of U.S.Non-Provisional application Ser. No. 15/015,597, filed on Feb. 4, 2016,and issued as U.S. Pat. No. 10,033,611, which claims the benefit ofpriority of U.S. Provisional Application No. 62/113,154, filed on Feb.6, 2015. The entire contents of the above applications are herebyincorporated by reference.

BACKGROUND

This specification relates in general to transaction tracking and, butnot by way of limitation, to transaction tracking within a network andpresentation of results relating to transaction tracking.

The growth of networks, both private and public, has resulted inincreasingly complex infrastructures that support communications withinthe networks. In an example network, in addition to the presence of endpoint nodes in the network, an underlying infrastructure can includemany other nodes through which a transaction must travel on its pathfrom an originating node to a destination node. The more nodes along itspath, the more likely it is that the transaction will not reach itsdestination node. The reasons why it may not reach its destination nodecan be various. For example, the transaction may have an improperaddress or an intermediate node may be offline or not processingtransactions appropriately. However, diagnosing the reason usingconventional methods of transaction tracking may prove burdensome, timeconsuming, and/or impossible. This is especially true when theindividual diagnosing lacks a first-hand understanding of the networkand infrastructure.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1. is an example block diagram illustrating an environment in whichtechniques relating to managing and tracking transactions within anetwork as described herein may be implemented, according to at leastone example;

FIG. 2. is an example block diagram illustrating an environment in whichtechniques relating to managing and tracking transactions within anetwork as described herein may be implemented, according to at leastone example;

FIG. 3 is an example schematic model illustrating an a networkcommunication model in which techniques relating to managing andtracking transactions within a network as described herein may beimplemented, according to at least one example;

FIG. 4 is an example schematic model illustrating an aspect of thenetwork communication model of FIG. 3 in more detail;

FIG. 5 is an example schematic model illustrating an aspect of thenetwork communication model of FIG. 3 in more detail;

FIG. 6 is an example schematic model illustrating an aspect of thenetwork communication model of FIG. 3 in more detail;

FIG. 7 is an example schematic model illustrating an aspect of thenetwork communication model of FIG. 3 in more detail;

FIG. 8 is an example schematic architecture illustrating a network inwhich techniques relating to managing and tracking transactions within anetwork as described herein may be implemented, according to at leastone example;

FIG. 9 is an example block diagram illustrating an environment in whichtechniques relating to managing and tracking transactions within anetwork as described herein may be implemented, according to at leastone example;

FIG. 10 is an example block diagram illustrating an environment in whichtechniques relating to managing and tracking transactions within anetwork as described herein may be implemented, according to at leastone example;

FIG. 11 is an example data table including information relating toimplementing techniques relating to managing and tracking transactionswithin a network as described herein, according to at least one example;

FIG. 12 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 13 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 14 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 15 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 16 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 17 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 18 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 19 is an example user interface illustrating techniques relating tomanaging and tracking transactions within a network as described herein,according to at least one example;

FIG. 20 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example;

FIG. 21 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example;

FIG. 22 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example;

FIG. 23 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example;

FIG. 24 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example;

FIG. 25 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example; and

FIG. 26 is a flow diagram depicting example acts for implementingtechniques relating to managing and tracking transactions within anetwork as described herein, according to at least one example.

DETAILED DESCRIPTION

The ensuing description provides preferred exemplary embodiment(s) only,and is not intended to limit the scope, applicability or configurationof the disclosure. Rather, the ensuing description of the preferredexemplary embodiment(s) will provide those skilled in the art with anenabling description for implementing a preferred exemplary embodiment.It is understood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope asset forth in the appended claims.

In one example, a method and system for tracking message transactions isprovided. The messages represent a variety of different types of digitalmessages that may be transferred between nodes of a network. Eachmessage that is transferred within the network may constitute a singletransaction. The flow of each transaction is tracked from itsoriginating node to its destination node and at all points in between.This tracking is performed in part by a transaction management engine.The transaction management engine is located within the network betweenoriginating nodes and destination nodes. In some examples, thetransaction management engine is coupled with a transformativeintegration engine or a similar engine that aggregates messages. In someexamples, the transaction management engine is included as part of astand-alone transaction management platform. In any event, once thetransaction management engine receives the message or an indication ofthe message, the transaction management engine generates a uniquemessage identifier. The unique message identifier may comprise a sourceapplication identifier, a source facility identifier, a message typeidentifier, a message control identifier, any other suitable identifier.The unique message identifier is then associated with the message viametadata (e.g., within the header of the message) such that when thenext node (e.g., component, device, server, etc.) receives the message,that node can report back to the transaction management engine that themessage has been received. Each node that receives the message can senda ping back to the transaction management engine.

In one example, message tracking information generated by a transactionmanagement engine is displayed using an interactive visualizationengine. The interactive visualization engine receives message trackinginformation and causes it to be displayed. In some examples, the messagetracking information is provided using one or more data service layersthat may or may not be in communication with the interactivevisualization engine. Display of the message tracking informationincludes providing a graphical diagram for presentation on a userinterface and dynamically adjusting the presentation of the graphicaldiagram to illustrate the movement of messages throughout a network andto illustrate the functional health of components (represented as nodes)of the network. The graphical diagram, therefore, includes a pluralityof nodes of the network connected with variably-sized chords connectingat least two nodes of the plurality. In some examples, thevariably-sized chords represent the movement of messages between thenodes of the network. The width of a chord between two particular nodesdepends on the number of messages that are represented by the nodes overa given time period. For example, when two nodes represent actualphysical facilities or components, the width of the chord may depend onthe number of messages flowing between the two nodes. However, when onenode represents a facility and the other node represents a message type,the width of the chord connecting the two nodes may depend on the numberof messages of the message type that flow into and/or out of thefacility. The nodes and the chords of the interactive visualization arerefreshed automatically and/or by user initiation. A user of theinteractive visualization can filter the message tracking informationbased on message type, source application, source facility, and otherparameters of the messages and can drill down to different levels ofgranularity within the information and over different time frames.

In one example, a reconciliation engine is provided that enablesreconciliation of messages. Reconciliation of messages may be desirablein a network to identify the reasons why messages are not movingproperly throughout the network. For example, messages may be held up ina cache of a node, negatively acknowledged by a node, and many otherreasons. By accessing the unique message identifiers and, in someexamples, other information output by the transaction management engineand information received from destination nodes, the reconciliationengine is able to determine which messages did not make it to theirrespective destination nodes. The information received from thedestination nodes may act as a confirmation that the messages were notlost or corrupted prior to delivery to the destination nodes. In someexamples, the reconciliation engine assigns a status to each messagewhich may include: not reconciled, waiting for reconciliation,reconciled, negatively acknowledged, acknowledged, combinations of theforegoing, and other suitable statuses. Using the reconciliation engine,a case can be created and provided to a user for further exploration.The case may include a list of messages, their status, and othersuitable information. Any of the data generated by the reconciliationengine may be provided for presentation on a user interface. The userinterface may include filters, menus, and the like to interact with thedata gathered by the reconciliation engine.

in one example, message tracking information generated by a transactionmanagement engine is used to track latency of messages as the messagestravel through a network. In this example, the message trackinginformation is used to drill down to the message level. Thus, a user mayuse the message tracking information to identify details aboutparticular messages. For example, tracking information relating todischarges of users may be collected and analyzed to determine whethercare was provided in a timely manner. Because the messages cancorrespond to actual events relating to the user (e.g., discharge of auser), the tracking of messages in this example can be used for servicelevel agreement compliance.

In one example, message tracking information is used by an anomalydetection engine for anomaly detection. In this example, the messagetracking information is monitored in combination with mathematicalformulas to determine if an appropriate amount of data is flowingthrough a network given a certain period of time. The appropriateness ofthe amount of data is determined by comparing what should have beenreceived (based on historical trends) with what has actually beenreceived. The data is represented by the messages which carry the data.In one example, based on historical trends, for a period beginning at12:00 am on Monday and ending at the current time (e.g., 12:00 pm) onthe same day, a particular component of the network is expected toreceive 10,000 messages of type A from location X. By analyzing themessage tracking information, it may be determined that only 8,000messages were received. Using this comparison, the system may identifyanomalies within the system, whether the anomaly be a particular node,network, or the like. The historical data that is used is specific tothe time period of interest. Thus, in the example above, the historicaldata for the 12-hour time period is the historical data for that same12-hour time period going back a predetermined number of weeks, months,or years. This historical data is calculated to determine an arithmeticaverage number of messages which can be used to compare with the currentnumber of messages. This provides rolling anomaly detection thatimproves as the data becomes more rich. The interactive visualizationengine receives message tracking information output by the anomalydetection engine and provides a graphical diagram for presentation on auser interface. The graphical diagram includes nodes and chords. In someexamples, the amount of messages is compared to one or more thresholdsto determine how threads that represent the messages should be shadedand/or colored. For example, yellow may indicate that the number ofmessages is a little low, red may indicate that the number of messagesis zero, blue may indicate that the number is close to normal, andpurple may indicate that the number is more than expected.

In one example, the technical health of components of a network ismonitored by a health monitor engine. The health monitor enginedetermines health information which represents the “health” ofcomponents based at least in part on message tracking information. Oncethe health information is determined, the interactive visualizationengine provides a graphical diagram for presentation on a userinterface. The graphical diagram provides a visualization of how thehealth of the components compare to other components, and to baselinesof health for the particular component. In some examples, the graphicaldiagram provides the health of components configured to integrate data(e.g., enterprise-level integration platforms). The health monitorengine may be configured to monitor one or more operationalcharacteristics of components to determine the health informationcorresponding to the components. For example, the health monitor enginemay monitor indications of fragments, suspended instances, suspendedmessages, and any other suitable operational characteristic. Themessages that correspond to the monitored operational characteristicscan be accessed in the graphical diagram and may be filtered by messagetype (e.g., pharmacy, clinical, etc.), origination location, originationsystem, and any other suitable filter criterion. In some examples, thehealth information is presented in a histogram and/or colored and/orshaded using thresholds. Using the health monitor engine may enable auser to see health of components and/or message volume healthirrespective of the platform or operating system from which the messagesoriginated. If the user identifies a problem, the user can click on anode that represents the component, and the user is directed to thenecessary screen for beginning to resolve the problem.

In one example, message tracking information generated by a transactionmanagement engine is displayed for identifying messages that may beaffected. The graphical display of these affected messages is refreshedon a near real-time or real-time basis. In some examples, the graphicaldisplay is a zoomable heat map that includes one or more boxesrepresentative of message types, origination location, or any othersuitable characteristic. The size of the boxes depends on the number ofaffected messages, the size of the boxes is relative to the other boxesbeing presented. In addition, the color, shading, fill, intensity ofcolors, or otherwise of the boxes can change depending on the percentageof effected messages. The diagram can also be filtered by latency andother filters to display other helpful information. Because the numberof and percentage of messages is presented, the areas that need to beaddressed by an authorized user are automatically prioritized. Based onthis, the user can quickly and efficiently determine where to focusrecovery efforts.

Referring first to FIG. 1, a block diagram of an embodiment of aninteraction system 100 is illustrated. Generally, in interaction system100, data can be generated at one or more system components 102 and/oruser devices 104. Transaction management engine 106 van manage the flowof communications within interaction system. Transformative processingengine 108 can receive, intercept, track, integrate, process and/orstore such data.

Data flowing in interaction system 100 can include a set ofcommunications. Each of one, some of all communications can include (forexample) an encoding type, authentication credential, indication of acontent size, identifier of a source device, identifier of a destinationdevice, identifier pertaining to content in the communication (e.g., anidentifier of an entity), a processing or reporting instruction, aprocedure specification, transmission time stamp, and/or sensormeasurement. Data may, or may not, selectively pertain to a particularentity and/or client. Data can, depending on the implementation, includeindividually identifiable information and/or de-identified informationas it pertains to an entity and/or client. Data may, but need not,include protected information.

For example, a system component 102 can include, for example, a sensorto detect a sensor measurement and can thereafter generate and transmita communication that reflects the sensor measurement. The communicationmay be transmitted at routine times and/or upon detecting a threshold(e.g., one or more) number of measurements or a measurement satisfying atransmission condition (e.g., exceeding a threshold value). In someinstances, the sensor measurement corresponds to one reflecting aproperty of an object or entity (e.g., person) near the sensor. Thecommunication may then include an identifier of the object or entity.The identifier can be determined, for example, based on detection of anearby electronic tag (e.g., RFID tag), a detected user input receivedat a user interface of component 102 and/or data in a correspondingcommunication received from a user device.

As another example, a user device 104 can be configured to detect userinput received at a user interface of the device. The user input caninclude, for example, an identifier of an object or entity, aninstruction, a characterization of an object or entity, anidentification of an assessment to be performed, a specification of anaggregation or data processing to be performed, and/or an identificationof a destination for a data-analysis report. User device 104 can furtherbe configured to detect user input requesting particular data, togenerate a request communication (e.g., to be sent to transformativeprocessing engine), to receive the requested data and/or to present thereceived data.

Data can include information that identifies a person, such as personalinformation and/or demographic information. For example, the informationcan identify a person's name, age, sex, race, physical address, phonenumber, email address and/or social security number. Data may includeinformation collected by a government agent, employer, insurer, orschool or university, that relates to a past, present, or futurecondition or status (e.g., pertaining to employment, politicalinvolvement, occupation, health, or financial status) of any individual.For example, data may include information about past events.

Data may identify an entity being evaluated and/or one at least partlyperforming an evaluation. For example, a communication may identify afirst company as one being evaluated and a second company as oneevaluating a quality of a product of the first company. As anotherexample, a communication may identify a first service plan of a firstcompany as one providing an Internet network and may identify one ormore users providing speed checks over the network.

The depicted engines, devices and/or components can communicate over oneor more networks. A network of one or more networks can include a wirednetwork (e.g., fiber, ethernet, powerline ethernet, ethernet overcoaxial cable, digital signal line (DSL), or the like), wireless network(e.g., Zigbee™, Bluetooth™, WiFi™, IR, UWB, WiFi-Direct, BLE, cellular,Long-Term Evolution (LTE), WiMax™, or the like), local area network, theInternet and/or a combination thereof. It will be appreciated that,while one or more components 102 and one or more user devices 104 areillustrated as communicating via transformative processing engine 108and/or transaction management engine 106, this specification is not solimited. For example, each of one or more components 102 may communicatewith each of one or more user devices 104 directly via other or the samecommunication networks.

A component 102 can be configured to detect, process and/or receivedata, such as environmental data, geophysical data, biometric data,chemical data (e.g., chemical composition or concentration analysisdata), and/or network data. The data can be based on data detected, forexample, via a sensor, received signal or user input. A user device 104can include a device configured to receive data from a user and/orpresent data to a user. It will be appreciated that, in some instances,a component 102 is also a user device 104 and vice-versa. For example, asingle device can be configured to detect sensor measurements, receiveuser input and present output.

A component 102 can be configured to generate a communication that is inone or more formats, some of which can be proprietary. For example, animaging machine (e.g., one of one or more components 102) manufacturedby company A, located within a first facility (e.g., facility 110), andbelonging to a first client, may save and transfer data in a firstformat. An imaging machine (e.g., one of one or more components 102)manufactured by company B, located within the first facility (e.g.,facility 110), and belonging to the first client, may save and transferdata in a second format. In some examples, data from certain componentsis transformed, translated, or otherwise adjusted to be recognizable bytransformative processing engine 108. Thus, continuing with the examplefrom above, when the imaging machines manufactured by companies A and Bare located within the first facility belonging to the first client,they may nevertheless save and transfer data in different formats. Insome examples, one or more components 102 communicate using a definedformat.

In some examples, each of one or more components 102 are each associatedwith one or more clients within a same or different interaction systems.For example, certain ones of one or more components 102 may beassociated with a first client, while other ones of one or morecomponents 102 may be associated with a second client. Additionally,each of one or more components 102 may be associated with a facility 110(e.g., client facility). Each facility 110 may correspond to a singlelocation and/or processing focus. Exemplary types of facilities includeserver farm facilities, web-server facilities, data-storage facilities,technical-support facilities, telecommunication facilities, carefacilities and/or business operation facilities. For example, a firstfacility may include a structure at a first location at which one ormore resources (e.g., computational resources, equipment resources,laboratory resources and/or human resources) are provided. Each of theone or more resources may be of a first type in a first set of types. Aresource type can be identified based on, for example, a characteristicof the resource (e.g., sensor inclusion) and/or a capability ofproviding each of one or more services. Thus, for example, resources ata first facility may be better configured for handling a particular typeof service requests compared to those in another facility. As anotherexamples, different facilities may include resources of similar or sametypes but may vary in terms of, for example, user accessibility,location, managing client, etc.

Transmission of data from one or more components 102 to transformativeprocessing engine 108 may be triggered by a variety of different events.For example, the data may be transmitted periodically, upon detection ofan event (e.g., completion of an analysis or end of a procedure), upondetection of an event defined by a rule (e.g., a user-defined rule),upon receiving user input triggering the transmission, or upon receivinga data request from transformative processing engine 108. Eachtransmission can include, e.g., a single record pertaining to a singleentity, object, procedure, or analysis or multiple records pertaining tomultiple entities, objects, procedures, or analyses.

In some examples, at least some of one or more user devices 104 areassociated with facility 110. In some examples, at least some of one ormore user devices 104 need not be associated with facility 110 or anyother facility. Similar to one or more components 102, one or more userdevices 104 may be capable of receiving, generating, processing and/ortransmitting data. Examples of one or more user devices 104 include, forexample, a computer, a mobile device, a smart phone, a laptop, anelectronic badge, a set-top box, a thin client device, a tablet, apager, and other similar user devices). One or more user devices 104 maybe configured to run one or more applications developed for interactingwith data collected by transformative processing engine 108. Forexample, those user devices of one or more user devices 104 that are notassociated with facility 110 may be configured to run one or morethird-party applications that may rely in part on the data gathered bytransformative processing engine 108.

Each of one or more components 102 and one or more user devices 104 maybe utilized by one or more users (not shown). Each of the one or moreusers may be associated with one or more clients. For example, one ofthe one or more users can be associated with a client as a result ofbeing employed by the client, physically located at a location of theclient, being an agent of the client or receiving a service from theclient.

In some examples, one or more components 102 and one or more userdevices 104 may communicate with transformative processing engine 108and transaction management engine 106 via different information formats,different proprietary protocols, different encryption techniques,different languages, different machine languages, and the like. As willbe discussed with reference to FIG. 2, transformative processing engine108 is configured to receive these many different communications fromone or more components 102, and in some examples from one or more userdevices 104, in their native formats and transform them into any of oneor more formats. The received and/or transformed communications can betransmitted to one or more other devices (e.g., transaction managementengine 106, an entity device and/or a user device) and/or locally orremotely stored. In some examples, transformative processing engine 108receives data in a particular format (e.g., the HL7 format) orconforming to any other suitable format and/or is configured totransform received data to conform with the particular format.

One or more components 102 of facility 110 can include and/or has accessto a local or remote memory for storing generated data. In someexamples, the data is stored by one or more servers local to facility110. Such storage may enable facility 110 to retain locally datapertaining to its facility prior to (or in conjunction with) the databeing shared with transformative processing engine 108 and/ortransaction management engine 106. In some examples, the one or moreservers of facility 110 share data directly with a record service (notshown), and the record service makes the data available totransformative processing engine 108 and/or transaction managementengine 106. Once an electronic record is updated at facility 110, anindication of the update may be provide to the record service. Therecord service may then update a corresponding record associated withthe electronic record.

The record service can be granted access to the data generated and/ortransmitted by one or more components 102. In some examples, the recordservice includes a server or a plurality of servers arranged in acluster or the like. These server(s) of the record service can processand/or store data generated by one or more components 102. For example,one or more records can be generated for each entity (e.g., each recordcorresponding to a different entity or being shared across entities).Upon receiving a communication with data from an component (orfacility), the record service can identify a corresponding record andupdate the record to include the data (or processed version thereof). Insome examples, the record service provides data to transformativeprocessing engine 108.

Facility 110 can include one at which a resource is located and/orservice is provided. Irrespective of the type of facility, facility 110may update data, maintain data, and communicate data to transformativeprocessing engine 108. At least some of the data may be stored local tofacility 110.

A user interacting with a user device 104 can include, for example, aclient customer, client agent and/or a third party. A user may interactwith user device 104 and/or component 102 so as to, for example,facilitate or initiate data collection (e.g., by a component 102),provide data, initiate transmission of a data request, access dataand/or initiate transmission of a data-processing or data-storageinstruction. In some instances, one or more user devices 104 may operateaccording to a private and/or proprietary network or protocols. In otherexamples, one or more user devices 104 may operate on public networks.In any case, however, transformative processing engine 108 can haveaccess to the one or more components and can communicate with them via apublic, private and/or proprietary network or protocols. The use of oneor more private and/or proprietary protocols can promote secure transferof data.

Referring next to FIG. 2, a block diagram of an example of aninteraction system 200 is shown. Interaction system 200 includes atransformative processing engine 202. Transformative processing engine202 is an example of transformative processing engine 108 discussed withreference to FIG. 1. Interaction system 200 also includes one or moregeneration components 204. In particular, one or more generationcomponents 204 includes an equipment component 206, a lab systemscomponent 208, a scheduling component 210 and other generation component212. One or more generation components 204 are examples of one or morecomponents 102 discussed with reference to FIG. 1.

Generally, one or more generation components 204 includes any suitabledevice or system capable of generating data in the context of aninteraction system. For example, the other generation component 212 mayinclude a sensor on a door, and equipment component 206 may include asophisticated computer-controlled laser device. In either case, eachgeneration component generates some type of data. For example, the dataprovided by the sensor may be used to address security concerns orassessing heating, ventilating, and air conditioning (HVAC) costs for aninstitution. The data provided by the laser device may have beenprovided while engaged in a procedure and may then be used by otherentities in the future to decide how to use the device.

As discussed in further detail herein, data generated by one or moregeneration components 204 can be of a variety of formats, some of whichmay be proprietary. For example, a single component can generate data inmultiple formats, different components can generate data in differentformats, and/or different component types can result in generation ofdata in different formats. In some instances, formatting of a data candepend on a service having been provided, a user initiating datageneration, a destination to receive the data, a location at which aservice was provided, etc. In some examples, a typical interactionsystem includes thousands of generation components producing data inhundreds of formats. In order to harness the power that comes from sucha large amount of data to make informed decisions, it is desirable thatall, or at least a large portion of the data, is shared. Use oftransformative processing engine 202 in accordance with techniquesdescribed herein may achieve this design—making large amounts of data,in many different originating formats available to various types ofusers, via one or more interfaces.

While one or more generation components 204 are illustrated adjacent toeach other, it is understood that each may be located within onefacility or that the components may be spread out among many facilities.In addition, in some examples, one or more generation components 204belong to different clients.

Turning now to equipment component 206, this component includes anymachine, contrivance, implant, or other similar related article, that isintended to aid in reaching a particular objective. In some instances,equipment component 206 includes one or more sensors to detectenvironmental or other stimuli. Equipment component 206 can include, forexample, equipment to monitor a stimulus, detect stimulus changes,detect stimulus-indicative values, and so on. Exemplary equipmentcomponents 206 include an imaging device, a device that detects andcharacterizes electrical signals, a device that detects pressure, and/ora device that detects concentration of one or more particular elements,compounds and/or gases.

As illustrated, equipment component 206 includes transformative adaptor216. In some examples, transformative adaptor 216 is a device thattransforms, translates, converts, or otherwise adjusts output data fromequipment component 206. For example, an equipment component 206 can bea scanner that outputs its results in format A, but the majority ofother scanners in the interaction system output their results in formatB. Transformative adaptor 216 may be implemented to convert or otherwiseadjust the results in format A to conform closer to format B. Forexample, the conversion from format A to format B may be performed usinga conversion rule, which may be user-define or learned. Transformativeprocessing engine 202 may perform similar tasks as it relates to alldata generated within interaction system 200. In this manner,transformative adaptor 216 can perform an initial step in the process oftransformation, translation, conversion, or adjustment of the output ofequipment component 206. In some examples, transformative adaptor 216 isimplemented in hardware, software, or any suitable combination of both.In some examples, other transformative adaptors (not shown) may beimplemented within others of one or more generation components 204. Insome examples, equipment component 206 may not include transformativeadaptor 216.

Lab systems component 208 includes any suitable laboratory equipment orsystem that is intended to analyze material, such as biologicalmaterial. This includes, for example, laboratory equipment that analyzesbiological samples; electric microscopes; ultracentrifuges; datacollection devices, including Kymographs, sensors connected to acomputer to collect data; monitoring devices; computers used to reportresults of lab tests, and other similar laboratory equipment. Each ofthe above-listed components generates data that is provided (directly orindirectly) to transformative processing engine 202.

Scheduling component 210 includes any suitable computing devices usedfor business-related purposes with respect to interaction system 200.For example, scheduling component 210 can be configured to schedule aresource for allocation for a particular entity during a particular timeslot. Scheduling component 210 can monitor a schedule for the resourceand can identify one or more available time slots that may be secured bya particular entity. Upon receiving a scheduling indication, schedulingcomponent 210 may update a schedule of a resource to reflect that aparticular time slot is to be allocated for service of a particularentity.

Each of one or more generation components 204 and the user device 228may include individual and/or shared storage systems, one or moreprocessors, a user interface, a network connectivity device, and one ormore ports. The storage system include memory that may be implemented,e.g., using magnetic storage media, flash memory, other semiconductormemory (e.g., DRAM, SRAM), or any other non-transitory storage medium,or a combination of media, and can include volatile and/or non-volatilemedia. The storage systems may also be configured to storecomputer-executable code or instructions for interacting with the userinterface and/or for one or more applications programs, such as anapplication program for collecting data generated by the particulargeneration component.

The one or more processors may be configured to access the operatingsystem and application programs stored within the storage systems, andmay also be configured to execute such program code. The one or moreprocessors can be implemented as one or more integrated circuits, e.g.,one or more single-core or multi-core microprocessors ormicrocontrollers, examples of which are known in the art. In operation,the one or more processors can control the operation of the particularcomponent. The one or more processors may access and execute the programcode and at any given time.

The user interface can include any combination of input and outputdevices. In some instances, a user can operate input devices of the userinterface to invoke the functionality of the particular component oruser device. For example, the user interface may enable the user toview, hear, and/or otherwise experience output from component or userdevice via the output devices of the user interface. Examples of outputdevices include a display, speakers, and the like.

The network connectivity device may enable the component or user deviceto communicate with transformative processing engine 202 and othercomponents or other user devices via one or more networks. The one ormore networks may include any suitable combination of cable, cellular,radio, digital subscriber line, or any other suitable network, which maybe wired and/or wireless. In some examples, the network connectivitydevice may enable the component or the user device to communicatewirelessly with various other components and/or transformativeprocessing engine 202. For example, the components may include circuitryto enable data communication over a wireless medium, e.g., usingnear-field communication (NFC), Bluetooth Low Energy, Bluetooth® (afamily of standards promulgated by Bluetooth SIG, Inc.), Zigbee, Wi-Fi(IEEE 802.11 family standards), or other protocols for wireless datacommunication.

The one or more ports may enable the component or the user device toreceive data from one or more sensors. The sensors may be any suitabletype of sensor to capture data. Such captured data may be shared withtransformative processing engine 202 in accordance with techniquesdescribed herein. In some examples, the sensors may also be configuredto detect the component's or the user device's location and otherdetails about the component or the user device. In some examples, thecomponent and user device may include global positioning chips fordetermining a geolocation. Such geolocation information may be relevantto analyzing the data provided by the component or the user devicelocated at the geographic location.

Transformative processing engine 202 includes an aggregation engine 218,an interoperability engine 220, an access management engine 222, aninterface engine 224, and a data store 226. Generally aggregation engine218 is configured to collect data from multiple communications. The datamay be from one or multiple generation components 204 and/or may be of asame or different formats. Aggregation engine 218 may be configured toperform one or more operations on the collected data. For example,aggregation engine 218 may tag data, log data, perform protocolconversion, and may support one-to-many communications. The collectionmay be asynchronous. In some examples, the data has been saved locallyin connection with one or more generation components 204 in manydifferent formats having many different data structures.

Aggregation engine 218 can identify data to be aggregated based on, forexample, intra-communication data, a current time, a source generationcomponent, and/or one or more aggregation rules. For example, anaggregation rule may specify that data is to be aggregated across allcommunications that include content with a same entity identifier. Anaggregation may be dynamic. For example, aggregated data may reflectthat from within a most recent 12-hour period. Thus, an aggregation maybe updated in time to exclude older data from the aggregation and toinclude newer data.

Aggregation engine 218 can be configured to provide data from one ormore communications to interoperability engine 220. Interoperabilityengine 220 can be configured to perform one or more operations on thereceived data and store it in data store 226. For example,interoperability engine 220 may perform semantic tagging and indexing ofdata. This may include extracting field values from data, categorizingdata (e.g., by type of data, characteristic of an entity, location offacility, characteristic of facility, and the like), anonymizing orpartially-anonymizing data, and the like. Interoperability engine 220may also include a high availability cache, an alerts engine and a rulesengine. In some examples, interoperability engine 220 operatessynchronously.

From interoperability engine 220, data flows to data store 226. Datastore 226 (and any other data store discussed herein) may include one ormore data stores, which may be distributed throughout two or moredifferent locations (e.g., present on different devices, which caninclude devices of different entities and/or a cloud server). In someexamples, data store 226 includes a general data store 230, anoperational data store 232, and an entity-based data store 234. Withineach of the data stores 230, 232, and 234 is stored data. Depending onthe structure of the particular data store, certain data stores mayinclude rules for reading and writing. The data stores 230, 232, and 234may include records, tables, arrays, and the like, which may berelational or non-relational. Depending on the data store, records forindividual entities, business and analytics information, output datafrom one or more generation components 204, and the like may beretained. The data within the data stores 230, 232, and 234 includeelements or tags such that a particular data (e.g., for a single entity,protocol, etc.) can be retrieved.

Access management engine 222 is configured to manage access to featuresof transformative processing engine 202, including access to the dataretained in data store 226. For example, access management engine 222may verify that a user device such as user device 228 is authorized toaccess data store 226. To verify the user device 228, access managementengine 222 may require that a user of the user device 228 input ausername and password, have a profile associated with the interactionsystem, have paid a subscription fee associated with access to datastore 226, and the like. Access management engine 222 may also verifythat the user device 228 has an IP address or geographical location thatcorresponds to an authorized list, that the user device 228 includes aplug-in for properly accessing data store 226, that the user device 228is running certain applications required to access data store 226, andthe like.

Interface engine 224 is configured to retrieve the data from data store226 and provide one or more interfaces for interacting with elements oftransformative processing engine 202. For example, interface engine 224includes an interface by which an application running on user device 228can access portions of data within data store 226.

Turning next to FIG. 3, an architecture stack 300 is shown. In someexamples, techniques relating management of data are implemented inaccordance with architecture stack 300. And while architecture stack 300is illustrated as having a particular structure, it is understood thatother structures, including those with more or less layers thanillustrated, is within the scope of this specification. In someexamples, architecture stack 300 is implemented across an interactionsystem having a plurality of systems belonging to the same client orspread across different clients. Thus, architecture stack 300 can beused to integrate different systems of different organizations,entities, and the like and to provide a fluid sharing of informationamong elements within the interaction system and without the interactionsystem. In some instances, a multi-layer part of architecture stack 300is implemented at a single system or device within an interactionsystem.

The different layers of architecture stack 300 will be describedgenerally with reference to FIG. 3 and in detail with reference tosubsequent figures. Architecture stack 300 includes a receiving layer302 as the bottom-most layer. Receiving layer 302 includes receivingdata from elements that share data with other elements within anaggregation layer 304. For example, as detailed herein, receiving layer302 can include receiving data from generation components that generatedata. As such, receiving layer 302 is where data that has been createdis received. In some examples, the data within receiving layer 302 maybe in its raw formats. The output may then be transmitted to aggregationlayer 304. In some examples, components of receiving layer 302 may havecomplimentary layers to facilitate data transfer. For example, thecomponents may include a data generation and/or a data transmissionlayer for providing data to receiving layer 302.

Elements of aggregation layer 304 aggregate the data generated by theelements of receiving layer 302. For example, the elements ofaggregation layer 304 may include aggregation engines that collect datafrom generation components located within receiving layer 302. Suchaggregation may be performed periodically, in response to a userrequest, according to a schedule, or in any other suitable manner. Insome examples, data of aggregation layer 304 may be aggregated accordingto input and/or rules and may aggregate across records pertaining to,e.g., a facility, entity, time period, characteristic (e.g., demographiccharacteristic or condition), outcome, and any other suitable inputand/or rules. The aggregation may include compiling the data, generatinga distribution, generating a statistic pertaining to the data (e.g.,average, median, extremum or variance), converting the data,transforming the data to different formats, and the like.

Next, architecture stack 300 includes an active unified data layer 308.Elements of active unified data layer 308 receive data from the elementsof the other layers and store such data in a unified manner. In someexamples, this may include storing the data in a manner that allows forlater searching and retrieval using a defined set of method calls,techniques, and or procedures. For example, the data may be stored suchthat a different application can access the data in a standard orunified manner. Thus, elements of active unified data layer 308 mayreceive information collected or generated within aggregation layer 304and make certain adjustments to the data (e.g., translations, tagging,indexing, creation of rules for accessing the data, conversion offormatting of the data, generation of compressed versions, and the like)prior to retaining the data within one or more data stores accessiblewithin active unified data layer 308.

Architecture stack 300 also includes an access management layer 310,which can include an audit/compliance layer 312 and/or an agency layer314. Access management layer 310 includes elements to manage access tothe data. For example, access management layer 310 may include elementsto verify user login credentials, IP addresses associated with a userdevice, and the like prior to granting the user access to data storedwithin active unified data layer 308.

Audit/compliance layer 312 includes elements to audit other elements ofarchitecture stack 300 and ensure compliance with operating procedures.For example, this may include tracking and monitoring the other elementsof access management layer 310.

Agency layer 314 includes an access location (e.g., a virtual privatenetwork, a data feed, or the like) for elements of agencies that areinterested in the operations of the interaction system in whicharchitecture stack 300 is implemented. For example, agency layer 314 mayallow a governmental entity access to some elements within architecturestack 300. This may be achieved by providing the governmental entity adirect conduit (perhaps by a virtual private network) to the elements ofaccess management layer 310 and the data within active unified datalayer 308. Audit/compliance layer 312 and agency layer 314 aresub-layers of access management layer 310.

Architecture stack 300 also includes interface layer 316. Interfacelayer 316 provides interfaces for users to interact with the otherelements of architecture stack 300. For example, clients, entities,administrators, and others belonging to the interaction system mayutilize one or more user devices (interacting within application/devicelayer 320) to access the data stored within active unified data layer308. In some examples, the users may be unrelated to the interactionsystem (e.g., ordinary users, research universities, for profit andnon-profit research organizations, organizations, and the like) and mayuse applications (not shown) to access the elements within architecturestack 300 via one or more interfaces (e.g., to access data stored withinactive unified data layer 308). Such applications may have beendeveloped by the interaction system or by third-parties

Finally, architecture stack 300 includes application/device layer 320.pplication/device layer 320 includes user devices and applications forinteracting with the other elements of architecture stack 300 via theelements of interface layer 316. For example, the applications may beweb-based applications, entity portals, mobile applications, widgets,and the like for accessing the data. These applications may run on oneor more user devices. The user devices may be any suitable user deviceas detailed herein.

Turning next to FIG. 4, a diagram 400 is shown that depicts a portion ofarchitecture stack 300 according to an embodiment of the invention. Inparticular, the diagram 400 includes receiving layer 302, aggregationlayer 304, aggregation layer 306, and a portion of active unified datalayer 308. Receiving layer 302 receives data from one or more components410-418. Components 410-418 are examples of one or more generationcomponents 204. Components 410-418 may be spread across multiplefacilities within a single or multiple clients. In some examples,components 410-418 may include complimentary layers to facilitate datatransmission. For example, components 410-418 may include a transmissionlayer, generation layer, and/or a receiving layer to communicate data atreceiving layer 302 and, in some examples, receive data from receivinglayer 302.

In some instances, two or more of components 410-418 generate dataaccording to different formats. The data can then be transformed,translated, or otherwise adjusted before an aggregation engine 420(e.g., aggregation engine 218) or a third-party aggregation engine 422(e.g., aggregation engine 218) collects the data. In some examples, theadjustment takes place within receiving layer 302. Thus, an adaptor 424is associated with component 412 located in receiving layer 302. Adaptor424 is an example of transformative adaptor 216. Adaptor 424 isimplemented, as appropriate, in hardware, software, or any suitablecombination of both. For example, transformative adaptor 216 may be abolt-on adaptor that adjusts data as such data leaves component 412.

Other adaptors, such as adaptor 426 and adaptor 428, are implementedwithin aggregation layer 304. These adaptors can function in a similarmanner as adaptor 424. In some examples, the data provided by component414 is transmitted through adaptor 426 prior to being directed toaggregation engine 420. The data provided by component 416 istransmitted through aggregation layer 304 and/or enters aggregationengine 420 without having first traveled through an adaptor. The dataprovided by component 418 is transmitted through aggregation layer 304and through adaptor 428. In some examples, component 418 provides forstreaming of data. The data provided by component 410 is transmitteddirectly to third-party aggregation engine 422.

Aggregation engine 420 and third-party aggregation engine 422 functionin a similar manner. In some examples, third-party aggregation engine422 is operated by a different entity than the entity that operatesaggregation engine 420 and may belong to different clients or adifferent interaction system. This may be because the data collected bythird-party aggregation engine 422 differs in some way from the datacollected by aggregation engine 420. In any event, aggregation engine420 is configured to perform integration of data, including genericintegration. For example, aggregation engine 420 performs one or moreoperations on data including tagging, logging, and protocol conversion.Aggregation engine 420 also supports one-to-many communications of data.In some examples, data flows between aggregation engine 420, thethird-party aggregation engine 422, and some of components 410-418 andelements of active unified data layer 308.

Referring next to FIG. 5, a diagram 500 is shown that depicts a portionof architecture stack 300 according to an embodiment of the invention.In particular, diagram 500 includes active unified data layer 308 and aportion of access management layer 310. Active unified data layer 308,as illustrated in diagram 500, includes an interoperability engine 502(e.g., interoperability engine 220), a transaction management collectionengine 504, a data store integrity engine 506, and a data store 508(e.g., data store 226). Generally, interoperability engine 502 receivesdata from elements within aggregation layer 304 (e.g., from aggregationengine 420) and performs one or more operations with respect to thedata. Interoperability engine 502 also facilitates storage of at least aportion of the processed information in data store 508.

Transaction management collection engine 504 is implemented as part oftransaction management engine 106. Transaction management collectionengine 504 is configured to generate message indicators identifyingflows of data by and between elements of an interaction systemimplemented using the techniques described herein. The flows ofinformation include messages which include data, and the messageindicators include unique message identifiers that can be used toidentify the messages. The unique message identifiers includeinformation that can be used to uniquely identify the messages. Forexample, a unique message identifier for a particular message caninclude a concatenation of the following information stored in a table:a source application, a facility, a message type, and a message controlidentification (ID). The unique message identifier can also be themessage control ID. The unique message identifier may be created asmessages including data are transmitted from aggregation layer 304. Thetable may be stored in association with the transaction managementplatform 528.

In some examples, the table also includes information for tracking theprogress of the message from an origination node to a destination node.For example, typically when a message (e.g., any communication of data)is first received by transformative processing engine 108 (e.g.,interoperability engine 502), transaction management engine 106 (e.g.,transaction management collection engine 504 of transaction managementengine 106) may generate a unique identifier for the message in order totrack that message as it moves throughout the interaction system. Theunique identifier may be included in the header of the message such thatwhen the next node (e.g., component, device, server, etc.) aftertransformative processing engine 108 receives the message, that node canreport back to transaction management engine 106 that it saw themessage. In this manner, transaction management engine 106 may enableend-to-end tracking of messages for the life of the message.

In one example, the messages are requests. The requests may be generatedbased om user input at one of the components. The requests may bereceived by transformative processing engine 108 and integrated into thesystem. In some examples, transaction management engine 106 may benotified that the requests have been received and may therefore beconfigured to generate message IDs for each request. These message IDsmay then be associated with each of the requests. As the requestscontinue to move throughout the interaction system (e.g., away fromtransformative processing engine 108), transaction management engine 106may be track their movement using the message IDs. If one of therequests does not make it to its destination, transaction managementengine 106 (or part of the transaction management platform 528) maydetermine why the request was stopped. In some examples, this cause maybe hardware related (e.g., an unplugged Ethernet cable, a broken router,etc.), software related (e.g., a router routing to the wrong location),or any other reason for orders not arriving at their correctdestination.

In some examples, transaction management engine 106 (e.g., transactionmanagement collection engine 504 of transaction management engine 106)may receive the message and/or message identifier directly from one ofcomponents 410-418. For example, one of components 410-416 may beconfigured to generate the unique message identifier and/or communicatedirectly with transaction management engine 106. The message also maytravel via one or more intermediate nodes on its way to the destinationnode. In some examples, a node is a component such as components410-418, which may be running an application. In some examples, theunique identifier and the routing of the message to its destination maybe stored in a table that also includes: a geolocation of each node, anetwork from which the message originated, a type of node, the uniquenode identifier, and a time associated with the message leaving theorigination node. In some examples, transaction management collectionengine 504 provides unique message identifiers to other elements of theinteraction system to monitor the messages as they move throughout theinteraction system. Transaction management collection engine 504 alsoprovides a portion of the unique message identifiers to a transactionmanagement platform (indicated by a circle 528) for further analysis ofthe message identifiers. Such analysis may include reconciliation oflost messages, latency reporting, audit management and compliance, andother such analyses.

As mentioned previously, interoperability engine 502 is configured tostore data in data store 508. A plurality of sub-engines 510-516 ofinteroperability engine 502 are configured to perform operationsrelating to storing data in data store 508.

Interoperability engine 502 includes a tagging engine 510 configured toperform semantic tagging and indexing of data. Tagging engine 510therefore is configured to receive data, read metadata associated withthe data, semantically scan the content of the data, and associate oneor more tags with the data. Tagging engine 510 may therefore have accessto hundreds, thousands, or even more possible tags. These tags may havebeen input by users, learned, pre-defined, generated by outsidethird-party mapping sources, and/or gathered from other componentsand/or data stores of the interaction system. For example, if the datais a chart for an entity, the tagging engine may be configured to readany metadata associated with the chart to determine which tags may beappropriate to associate with the chart. From the metadata, taggingengine 510 may determine that the chart is for a type of entity byreading metadata indicating that an author field is populated with thename of another particular type of entity. Tagging engine 510 may haveaccess to other data to compare the analyzed metadata against (e.g., toidentify that the author's name corresponds to Dr. Brown who is anoncologist). Other examples, of metadata that may be included in one ormore fields include author, document type, creation time and date, lastupdate time and date, upload time and data, geographic location, uniqueID associated with the client or facility where the data originated, andother similar fields. The tags may be stored in association with thedata (e.g., the chart) and/or may be stored independent from the databut include an identifier such that when searching tags the data may becapable of population.

Continuing with the example from above, if the data is a chart for afirst type of entity, tagging engine 510 may be configured to read thecontent of the chart to determine which tags may be appropriate toassociate with the chart. For example, this may comprise analyzing thecontent of the chart (i.e., individual pages) semantically to look forartifacts (e.g., keywords, phrases, and the like) in the content. Theseartifacts may be identified by tagging engine 510 and used to decidewhich tags to associate with the document. In some examples, semanticscanning may involve filtering out words (e.g., articles, such as “a”and “the”), phrases, and the like. Similar to the reading of metadata,the tags may be pre-defined, user-defined, learned, and the like. Insome examples, reading metadata associated with messages may providemeaning and/or give context to the particular record of data. Thismeaning and/or context may assist tagging engine 510 to determine one ormore tags to associate with the data. The tags may be chosen, forexample, based on values of particular fields in the data, detecting afrequency of one or more words in a document or metadata and/or of a setof related words (e.g., tagging a record with “cancer” upon detectingwords such as tumor, metastasize, chemotherapy, radiation, oncology,malignant, stage 3, etc.). In this manner, tagging engine 510 may alsoindex portions of the data within one or more data stores of data store508. In some examples, such indexing may be based in part on theselected tags.

Interoperability engine 502 also includes a reports engine 512configured to generate one or more reports or alerts based on data. Forexample, reports engine 512 may generate reports when certain types ofdata are received or when data with certain characteristics is received.Reports engine 512 may also generate alerts. The reports and/or alertsgenerated by reports engine 512 may be outputted in the form of one ormore communications to an administrator, an authorized user, or othersimilar user via a user device. Such communications can include, forexample, signals, sirens, electronic notifications, popups, emails, andthe like. Content of such communications may include informationcharacterizing a performance metric, efficiency and/or outcomes;identifying concerning patterns; identifying losses of data; and thelike. In some examples, the content is presented in the form of one ormore documents, tables, figures, charts, graphs, and the like.

Interoperability engine 502 also includes a rules engine 514 configuredto create and manage business rules, condition-response rules,alert/reports rules, data-formatting rules, data-sharing rules,transmission rules, aggregation rules, user authorization rules, andother similar rules. Such rules may be user-defined, fixed, learned byelements of the interaction system, and any combination of theforegoing. Finally, interoperability engine 502 includes an applicationengine 516 configured to provide service-oriented architecture webservices.

Data store 508 includes an electronic record information data store 518(“record data store 518”), a general data store 520, an operational datastore 522, an entity-based data store 524, and a streaming cachingstorage 526. While data store 508 is illustrated as including a fixednumber of data stores and storage elements, it is understood that datastore 508 can include any suitable number of data stores and storageelements, including more than illustrated or less than illustrated.

In some examples, a data query script is provided to query a first datastore and/or to obtain data for populating a data store. Such scriptcould query a data store described herein (e.g., data store 508) and/orcould be used to obtain data to populate a data store described herein(e.g., data store 508). In one instance, the script is configured to berepeatedly executed, so as to repeatedly draw data from a source datastore. The retrieved data can then be formatted, filtered, sorted and/orprocessed and then stored, presented and/or otherwise used. In thismanner, the script can be used to produce streaming analytics.

In some instances, the data query script, when executed, identifies eachof the data stores of interest. Identifying the data stores of interestinvolves identifying at least a portion of data from the data storessimultaneously and/or sequentially. For example, the script can identifycorresponding data stores (e.g., or components of a single data store ormultiple data stores) that pertain to one or more similar variables butthat differ in one or more other variables. Once the portion of the datafrom the data stores is identified, a representation of the identifieddata can be output to one or more files (e.g., Extensible MarkupLanguage (XML) files) and/or in one or more formats. Such outputs canthen be used to access the data within one or more relational databaseaccessible using Structured Query Language (SQL). Queries made using SQLcan be made sequentially or in parallel. Results from an SQL query maybe stored in a separate database or in an XML file that may be updatedeither in part or as a whole. The data query script may be executedperiodically, in accordance with a user-defined rule, in accordance witha machine-defined or machine-learned rule, and in other suitable manner.

[Within record data store 518 is retained data including electronicrecord information. In some examples, the information within record datastore 518 is organized according to entity identifying information.Thus, record data store 518, in some examples, includes individuallyidentifiable information. But it may also include de-identifiedinformation.

Within general data store 520 is retained data. The data may be storedin a relational database format or in any other suitable format. Thus,the data within general data store 520 may be retained in a datastructure that includes one or more tables capable of accessing eachother. In some examples, general data store 520 includes a subset of theinformation that is included in operational data store 522.

Within operational data store 522 is retained data in a relationaldatabase format. Thus, the data within operational data store 522 may beretained in a data structure that includes one or more data structures(e.g., tables) capable of accessing each other. Operational data store522 is an example of an operational data warehouse. In operational datastore 522 is joined many different types of data. F2. In some examples,the operational data ware house 522 includes data pertaining to decisionmaking as discussed herein and other data typically used by conventionalbusiness concerns.

Within entity-based data store 524 is retained data in a non-relationaldatabase format. Thus, the data within entity-based data store 524 maybe retained in a structure other than tables. Such structure may beappropriate for large and complex data sets. In some examples,entity-based data store 524 (or any other data store) may be a unifiedsystem, which may include: a document-centric, schema-agnostic,structure-aware, clustered, transactional, secure, database server withbuilt-in search and a full suite of application services. An example ofsuch a unified system may be Marklogic. Entity-based data store 524 cansupport data aggregation, data organization, data indexing, data taggingand mapping to semantic standards, concept matching, concept extraction,machine learning algorithms, concept discovery, concept mining, andtransformation of personal record information. In some examples,entity-based data store 524 includes data pertaining to decision making(similar to general data store 520) as discussed that is organized andaccessed in a different manner. For example, the data withinentity-based data store 524 may be optimized for providing and receivinginformation over one or more information exchanges. In some examples,entity-based data store 524 includes a subset of the information that isincluded in operational data store 522.

Finally, in some examples, streaming caching storage 526 is a streamingdata cache data store. As discussed previously, certain components ofcomponents 410-418 may support streaming data to other components oruser devices. Streaming caching storage 526 is a location wherestreaming data can be cached. For example, assume that component 418 isa piece of equipment operating at Location A and that a user using acomputer in Location B desires to view a live of substantially livestream of outputs of the piece of eqiupment. Component 418 can send aportion of data to streaming caching storage 526 which can retain theportion of the data for a certain period of time (e.g., 1 day). Thus,streaming caching storage 526 is configured to cache data that can bestreamed.

Diagram 500 also includes data store integrity engine 506. In someexamples, data store integrity engine 506 is configured to ensureintegrity of the information within data store 508. For example, datastore integrity engine 506 applies one or more rules to decide whetherinformation within all or part of data store 508 should be scrubbed,removed, or adjusted. In this manner, confidence is increased that theinformation within data store 508 is accurate and current.

FIG. 6 shows a diagram 600 which depicts a portion of architecture stack300 according to an embodiment of the invention. In particular, thediagram 600 includes access management layer 310, audit/compliance layer312, agency layer 314, and a portion of interface layer 316.

Access management layer 310, as illustrated in the diagram 600, includesan access management engine 602. Access management engine 602 is anexample of access management engine 222. Generally, access managementengine 602 can be configured to manage access to elements oftransformative processing engine 202 by different components,applications, and user devices.

Access management engine 602 within access management layer 310 alsoprovides functionality similar to an operating system. For example,access management engine 602 includes a plurality of engines configuredto manage different aspects of interacting with elements of theinteraction system. For example, a user who desires to access portionsof data retained in data store 508, may do so by interacting with accessmanagement engine 602 using one or more applications (not shown). Thus,access management engine 602 includes a variety of engines to enablesuch interaction. The engines include, for example, an authenticationaccess engine 604, a login engine 606, a user preference engine 608, asecurity engine 610, an analytics and search engine 612, a data accessengine 614, an update engine 616, and a streaming data engine 618. Thedifferent engines of access management engine 602 can define routines,protocols, standards, and the like for interacting with elements of theinteraction system.

Beginning first with authentication access engine 604, authenticationaccess engine 604 evaluates the rules and conditions under which usersmay access elements of the interaction system; in particular, theconditions under which users may access data within data store 508.These rules and conditions may be user-defined (e.g., by anadministrator or reviewer), learned over time, and/or may be dynamicallyupdated and/or evaluated based on characteristics of the user or theuser's device attempting to access the interaction system. The rules andconditions may indicate the types of users who have particular types ofaccess within the interaction system. The type of access may also relateto the degree to which data is identified/de-identified. In someexamples, a user desiring access to data provides certain identifyinginformation and authentication access engine 604 authenticates anidentity of the user.

Login engine 606 evaluates the rules and conditions under which usersare able to log in to the interaction system or access applicationsassociated with the interaction system. These rules and conditions maybe user-defined (e.g., by an administrator), learned over time, and alsomay be dynamically updated and/or evaluated based on characteristics ofthe user or the user's device attempting to access the interactionsystem. Thus, while authentication access engine 604 evaluates the rulesto determine which users may access the interaction system, login engine606 evaluates the particular credentials, profiles, etc. of the users.For example, login engine 606 can confirm that an entered username(e.g., and password), provided biometric data or code or identifier in ascanned tag or badge matches that in an authorized user data structure.

Login engine 606 evaluates one or more user profiles associated witheach authenticated user. In some examples, a user profile includes ausername, password, and other information associated with the user. Forexample, a user profile may indicate characteristics about the user.

User preference engine 608 evaluates the rules and conditions underwhich user are able to store and update one or more user preferencescorresponding to access of the interaction system or access toapplications associated with the interaction system. These rules andconditions may be user-defined (e.g., by the user or administrator), andmay include rules for default preferences. For example, using userpreference engine 608, a user may indicate a format in which the userprefers to receive outputted information, display characteristics of agraphical user interface associated with the user, and other similaruser preference settings. For example, the user may indicate thatcertain types of reports and/or alerts are to be sent to the user.

Security engine 610 evaluates the rules and conditions for ensuring thesecurity of access to the elements of the interaction system. In someexamples, these rules and conditions are determined by administrators ofthe interaction system. In some examples, security engine 610 provides aplurality of computer virus protection services. These services can becalled up and implemented when accessing the interaction system oraccessing applications associated with the interaction system. The rulesand conditions may be based on roles, based on profiles, based ondomains, and any other suitable security configuration. For example,because the interaction system may include sensitive data, securityengine 610 may enforce a domain-based rule that protects certainsensitive information (e.g., identifying information).

Analytics and search engine 612 evaluates the rules and conditions underwhich users can search for data within the interaction system and accessanalytics relating to the interaction system. In some examples, theserules and conditions are user-defined or learned over time in accordancewith search engine optimization techniques. For example, analytics andsearch engine 612 is used to search within data store 508 for particulardata. Analytics and search engine 612 supports any conventionalsearching algorithms. For example, search engine 612 can be used tosearch within various fields and potential field values. In someexamples, search engine 612 can provide analytics, such as statistics,graphs, distributions and/or comparative analysis pertaining toparticular entities and/or characteristics. Such information may beselected by a user and presented on a user interface.

Data access engine 614 evaluates the rules and conditions under whichusers may operation in order to access particular data within data store508. In some examples, these rules and conditions are user-defined orlearned over time. For example, data access engine 614 may indicate theroutines, subroutines, or other logic needed for an application toaccess certain portions of data store 508. For example, whileauthentication access engine 604 and login engine 606 may manage whichusers can access parts of the interaction system, data access engine 614may manage how authenticated users access data within data store 508. Tothis end, data access engine 614 may enforce and/or evaluate certainrules managing how users access different components of the interactionsystem. In some examples, data access engine 614 may be used to actuallyaccess data within data store 508 (e.g., extract, download, or otherwiseaccess). In some examples, data access engine 614 may define procedures,protocols, and the like for accessing data. The protocols and proceduresfor accessing data access engine 614 (like the other engines of accessmanagement engine 602) may be provided to developers in the form of asoftware development kit (SDK). SDKs may enable developers writeapplications that can effectively communicate with elements (e.g., datastore 508) of the interaction system. In particular, applications thatcan access a portion of the data stored within active unified data layer308.

Update engine 616 evaluates the rules and conditions for providingupdates to other engines within access management engine 602, plug-insfor applications that access the interaction system, and for othersimilar elements of the interaction system. For example, updates may begenerated at runtimes, at defined time intervals, upon request by auser, upon receiving a threshold quantity of new or changed data. Oncean update is performed, an interface may be refreshed, a report may besent indicating that the update was successful or unsuccessful, or thelike.

Streaming data engine 618 defines the rules and conditions for enablingstreaming of data between components and user devices of the interactionsystem. For example, streaming data engine 618 may enable component 414to stream data. Streamed data may include live or substantially liveaudio or video feeds, results of tests, output from equipment ordevices, and any other suitable type of data capable of being streamed.In some examples, the data may be streamed to other components or userdevices within the network or outside the network. In order to establisha streaming transmission, streaming data engine 618 may identify astreaming destination and a streaming origin. Next, streaming dataengine 618 may pair the two and enable streaming. This may includeallocated bandwidth within one or more network devices associated withthe interaction system. Streaming data engine 618 may also adjust thequality of the streaming data based on the availability of bandwidth. Insome examples, streaming data engine 618 may receive incoming streams(and continuously present the stream or monitor for particular data(e.g., exceeding a threshold, exhibiting an above-threshold change,having a particular value)).

Within audit/compliance layer 312 is located an access log engine 622.Access log engine 622 evaluates the rules and conditions for loggingaccess to the interaction system by users, applications, devices, andthe like. Logging access includes, in some examples, logging dataconventionally collected by access log engines running in similarenvironments. Access log engine 622 can use this data to generate andtransmit reports, for example, to stakeholders of the interaction systemsuch that they can make informed decisions regarding that is accessingthe interaction system and for what purposes.

Within agency layer 314 is located an agency engine 624. Agency engine624 evaluates the rules and conditions under which agencies can accessthe interaction system. For example, agencies that may use agency engine624 include agencies to which the interaction system providescompliance, tracking, or other reporting information. For example,agency engine 624 may be used to track one or more performanceindicators identified by a government agency and/or to provide reportinstances of defined types of events. Thus, in some examples, agovernment agency uses agency engine 624 to collect data pertaining tocompliance of the interaction system with one or more statutes orregulations. In some examples, a university is an agency that usesagency engine 624 to collect data pertaining to one or more studies. Insome examples, agency engine 624 can identify one or more entities(e.g., governmental agencies) that are to receive reports pertaining tooperations or events and what types of data are to be reported to thoseentities. Agency engine 624 can then collect the pertinent data,potentially format and/or analyze the data, and facilitate transmissionof (e.g., raw, formatted and/or analysis of) the data to the appropriateagency.

FIG. 7 shows a diagram 700 which depicts a portion of architecture stack300 according to an embodiment of the invention. In particular, diagram700 includes interface layer 316, and application/device layer 320.Within interface layer 316 is located interface engine 702 (e.g.,interface engine 224). Interface engine 702 is configured to generateone or more interfaces (e.g., graphical user interface 726, programmaticinterface 728, and/or web interface 730) to enable data to flow to userdevices 710, 712, and 714 via respective applications 720, 722, and 724.In some examples, the interfaces of interface engine 702 are embodied inhardware, software, or some combination of both. Within interface layer316 communications and inputs directed to interacting with elements ofaccess management layer 310 may be embodied.

Graphical user interface 726 is any suitable graphical user interfaceconfigured to interact with elements of the interaction system.Programmatic interface 728 includes an application programminginterface, a programmatic user interface, and other similar interfacesfor defining core functions for accessing elements of the interactionsystem. For example, programmatic interface 728 may specify softwarecomponents in terms of their operations. Web interface 730 is anysuitable web interface configured to interact with elements of theinteraction system. Any of the interfaces described herein may beconfigured to receive user input, present dynamic presentations thatdepend on user input, and otherwise respond to user input. In someexamples, such input may be provided via one or more input devices(e.g., a keyboard, touchscreen, joystick, mouse, microphone, devicescapable of capturing inputs, and the like) operated by one or more usersof user devices 706-714. Output may be provided via one or more outputdevices (e.g., a display or speaker).

Interface engine 702 is utilized by applications internal to theinteraction system and external to the interaction system to accessdata. In some examples, the applications that are internal includeapplications that are developed for internal use by various entitiesassociated with the interaction system. In some examples, theapplications that are external to the interaction system includeapplications that are developed for external use by those that are notassociated with the interaction system.

Generally, within application/device layer 320, applications 716-724which communicate with other elements of architecture stack 300 usingthe interfaces generated by interface engine 702 are defined. Thisincludes detailing how applications 716-724 are to interact with theinterfaces generated by interface engine 702 for accessing data. Forexample, interacting may include accepting inputs at user devices706-714 to access data and, in response, providing the data, prompts, orother types of interaction with one or more users of the user devices716-714. Thus, applications 716-724 may be related to one or more of theinterfaces generated by interface engine 702. For example, application720 may be interact with a graphical user interface (whether generatedby interface engine 702 or otherwise) to interact with other elements ofthe interaction system. Interacting may include receiving inputs at thegraphical user interface via application 720, providing output data tothe graphical user interface application 720, enabling interaction withother user devices, other applications, and other elements of theinteraction system, and the like. For example, some of the inputs maypertain to aggregation of data. These inputs may include, for example,types of data to aggregate, aggregation parameters, filters ofinterested data, keywords of interested data, selections of particulardata, inputs relating to presentation of the data on the graphical userinterface, and the like. Providing output data may include providing theaggregated data on the graphical user interface, outputting theinformation to one of the other user devices 706-714 running one of theother applications 716-724.

Turning now to the details of applications 720, 722, and 724. In someexamples, applications 720, 722, and 724 include a variety of differentapplications that can be designed for particular users and/or uses. Inone example, application 720 includes dashboards, widgets, windows,icons, and the like that are customized for an particular entity. Insome examples, application 720 may present different data depending on aspecialty associated with the entity and protected informationassociated with the entity. In this manner, application 720 adapts andautomatically adjusts depending on the context in which the entity isusing the application. In some examples, the data indicates performancestatistics for the entity, metrics relating to where the entity fallsalong a distribution of other similar entities, outlier instances,trends in events or actions, and the like. Application 720 may beconfigured to receive input, adjust presentations, present unpromoptedalerts, adjust display of content, move more relevant content to theforeground, move less relevant content to the background, populate formsfor the entity.

In another example, application 722 may be specific for nurses or typesof nurses. In this example, application 722 may include dashboards,widgets, windows, icons, and the like that are customized to individualnurses. Similar to the example discussed above pertaining to the doctor,in some examples, application 724 may present different data dependingon a position of the nurse. In this manner, application 722 adapts andautomatically adjusts depending on the context in which the nurse isusing the application. For example, the nurse may receive data, such astest results.

In some examples, application 724 may be a multi-role application foradministrators and is used to manage entities constitute the populationof the entities or organizations within the interaction system. Similarto the other examples discussed, in some examples, application 724 maypresent different data depending on a role of the user who is usingapplication 724. In this manner, application 724 adapts andautomatically adjusts depending on characteristics of the user who isusing application 724. In this manner, application 724 can providedifferent data depending on the role of the user. For example, whetherdata presented includes identifiable or de-identified information maydepend on a position of the user.

In some examples, application 724 may be a business intelligenceapplication. In this example, application 724 is used to displaybusiness information generated by components of the interaction system.This business information can be used for operations, planning, andforecasting. Such business information may include data because suchdata may impact operations, planning, forecasting, and the like.Accordingly, application 724 may present de-identified information inthe form of one or more metrics, indicators, or the like as they pertainto business intelligence.

Applications 716 and 718 shown in connection with interface engine 702are applications developed by third-parties. In some examples, suchapplications include any suitable application that benefits fromaccessing data. The interaction system may include data pertaining tohundreds of thousands of entities. Having data pertaining to so manyentities presents security concerns. For example, much of the data maybe identifying data. Accordingly, data that may be accessed byapplications 716 and 718 may be limited. In some examples, an entity ofthe interaction system may use one of applications 716, 718 to accesshis or her own data. In this example, the identity of the entity may beverified in accordance with techniques described herein.

User devices 706-714 are any suitable user devices capable of runningapplications 716-724. User devices 706-714 are examples of the userdevice 228. In some examples, the user devices include: mobile phones,tablet computers, laptop computers, wearable mobile devices, desktopcomputers, set-top boxes, pagers, and other similar user devices. Insome examples, at least some of user devices 706-714 are the samedevices as at least some of the one or more components 410-418. In someexamples, user devices 706-714 may include complementary layers toapplication/device layer 320 and/or receiving layer 302. For example,user devices 706-714 may include a transmission layer, a generationlayer, and/or a receiving layer to communicate data atapplication/device layer 320 and at receiving layer 302.

Turning now to FIG. 8, an interaction system 800 is shown in accordancewith an embodiment of the invention. Interaction system 800 includes aninternal organization 822 including a transformative processing engine802. The transformative processing engine 802 is an example oftransformative processing engine 202 previously discussed. Interactionsystem 800 is illustrated as an example configuration for implementingthe techniques described herein. In particular, a configuration ofelements as illustrated in FIG. 8, at least in some examples,communicates according to the layers of architecture stack 300. Forexample, internal organization 822 includes generation components804(1), 804(2), and 804(N) which provide data to aggregation servers806(1)-806(N).

Generation components 804(1), 804(2), and 804(N) operate in accordancewith receiving layer 302. In some examples, generation component 804(1)is a piece of equipment, generation component 804(2) is computer with adata collection device, a type of lab system, and generation component804(N) is a terminal. Aggregation servers 806(1)-806(N) operate inaccordance with aggregation layer 304. Aggregation servers 806(1)-806(N)share data with data storage servers 808(1)-808(N) via one or moreinternal network(s) 810. In some examples, internal network 810 is anysuitable network capable of handling transmission of data. For example,internal network 810 may be any suitable combination of wired orwireless networks. In some examples, internal network 810 may includeone or more secure networks. Data storage servers 808(1)-808(N) areconfigured to store data in accordance with active unified data layer308. Data storage servers 808(1)-808(N) include database servers, filestorage servers, and other similar data storage servers.

Access management servers 812(1)-812(N) manage access to the dataretained in the data storage servers 808(1)-808(N). Access managementservers 812(1)-812(N) communicate with the other elements of interactionsystem 800 via internal network 810 and in accordance with accessmanagement layer 310.

Interface servers 814(1)-814(N) provide one or more interfacesapplications to interact with the other elements of interaction system800. Interface servers 814(1)-814(N) provide the one or more interfacesand communicate with the other elements of interaction system 800 viainternal network 810 and in accordance with interface layer 316. Theinterfaces generated by the interface servers 814(1)-814(N) can be usedby internal user devices 816(1)-816(N) and external user devices 818(1),818(2), and 818(N) to interact with elements of interaction system 800.

Internal user devices 816(1)-816(N) are examples of user devices706-714. In some examples, internal user devices 816(1)-816(N) runapplications via the interfaces generated by interface servers814(1)-814(N). As an additional example, external user devices 818(1),818(2), and 818(N) can run applications developed by third parties thataccess the other elements of interaction system 800 via the interfacesgenerated by interface servers 814(1)-814(N).

External user devices 818(1), 818(2), and 818(N) access the interfacesvia external network 820. In some examples, external network 820 is anunsecured network such as the Internet. External user devices 818(1),818(2), and 818(N) are examples of user devices 706-714. External userdevice 818(1) is a mobile device. In some examples, the mobile devicemay be configured to run an application to access interaction system800. Similarly, the other external user devices 818(2)-818(N) runapplications that enable them to access interaction system 800. Whileinteraction system 800 is shown as implemented using discrete servers,it is understood that it may be implemented using virtual computingresources and/or in a web-based environment.

FIG. 9 illustrates a block diagram of a message tracking architecture900 in accordance with an embodiment of the invention. The messagetracking architecture 900 includes the transaction management platform902. The message tracking architecture 900 may be implemented using atleast some of the elements of the network 800. For example, thetransaction management platform 902 is an example of the transactionmanagement platform 528 discussed herein. The message trackingarchitecture also includes transformative integration engine 904, whichis an example of the transformative processing engine 108. Thetransformative integration engine 904 includes a transaction managementengine 906(A). The transaction management platform 902 also includes atransaction management engine 906(B). The transaction management engines906(A), 906(B) are examples of the transaction management engine 106discussed herein. The transaction management engines 906(A), 906(B) areconfigured to track messages using unique message identifiers asdiscussed herein.

Sending systems 908 are configured to provide data to receiving systems910. In some examples, the data moves in the form of one or moremessages via the transformative integration engine 904 and/or thetransaction management platform 902. The sending systems 908 include anysuitable computing system used in a network to generate and/or processdata. Examples of the sending systems 908 include clinical data systems,electronic medical record services, data centers, servers, computers,medical devices, and any other suitable component, such as thegeneration component 106 or the user device 104 capable of generatingand/or processing data. In some examples, the elements of thetransaction management platform 902 may be considered nodes of anetwork. In this example, the sending systems 908 may be consideredsource nodes and/or origination nodes. The sending systems 908 may besource nodes because data is originating at the sending systems 908 asit moves throughout the network.

The receiving systems 910 are configured to receive data from thesending systems 908. In some examples, the data is received via thetransformative integration engine 904 and/or the transaction managementplatform 902. The receiving systems 910 include any suitable computingsystem used in a network to receive and/or process data. Examples of thereceiving systems 910 include clinical data systems, electronic medicalrecord services, data centers, servers, computers, medical devices, andany other suitable component, such as the generation component 102 orthe user device 104 capable of receiving and/or processing data. In someexamples, the elements of the transaction management platform 902 may beconsidered nodes of a network. In this example, the receiving systems910 may be considered destination nodes or pathway nodes. The receivingsystems 910 may be destination nodes at least because data is receivedby the receiving devices 910 as it moves throughout the network. Thereceiving systems 910 may be pathway nodes at least because medicalrelated data is passed between some of the receiving systems 910 beforeending at one or more of the receiving systems 910.

In some examples, the transformative integration engine 904 is anenterprise level integration engine and may be configured to receivedata from a variety of different sources (e.g., the sending systems 908)and make such data available to other engines and services associatedwith the message tracking architecture 900. The transaction managementengine 906(A) may be associated with the transformative integrationengine 904 such that when the data (e.g., messages) is received by thetransformative integration engine 904, the transaction management engine906(A) may access that data to generate corresponding unique messageidentifiers for tracking the data (e.g., messages) within a network. Theunique message identifiers, which may be referred to herein as messagetracking information, may be provided to the transaction managementplatform 902. The transaction management platform 902 includes a varietyof engines, services, and storage elements configured to track movementsof messages, using the unique message identifiers, throughout a network.

The transaction management platform 902 includes the transactionmanagement engine 906(B), a reconciliation engine 912, a notificationengine 914, an anomaly detection engine 916, a health monitor engine918, and an interactive visualization engine 920. In some examples, eachof the engines of the transaction management platform 902 comprisessoftware and/or hardware that is configured to implement the messagetracking techniques described herein. The engines are provided asexamples, and it is understood that more or fewer engines may performthe operations described herein. The transaction management engine906(B) is configured to receive messages and/or indications of messagesfrom the sending systems 908. In some examples, the transactionmanagement engines 906(A) and 906(B) perform similar roles. In anyevent, once a message is received, the transaction management engine906(B) generates a unique message identifier that is unique to themessage. The unique message identifier may be a hexadecimal,hexadecimal, or any other suitable combination of letters, numbers,symbols, and the like.

The transaction management engine 906(B) generates a record for themessage and associates the unique message identifier with the record andstores the record in the transaction management storage 922. Asdescribed in more detail herein, the record may include various types ofdata that are particular to the message. The transaction managementstorage 922 may include any suitable number of data stores or othersuitable storage devices. The transaction management engine 906(B) alsoincludes the unique message identifier with the message. This mayinclude altering the message to include the unique message identifier.For example, the transaction management engine 906(B) may include theunique message identifier in the header of the message. Instructions mayalso be included in the header of the message in association with theunique message identifier. In some examples, the unique messageidentifier and/or the instructions may instruct later nodes to reportback to the transaction management platform 902 once the message isreceived. For example, once a particular receiving system of thereceiving systems 910 receives the message, the particular receivingsystem provides a message back to the transaction management platform902. The transaction management platform 902 then updates the recordassociated with the message that is stored in the transaction managementstorage 922.

The reconciliation engine 912 is configured to generate data that can beused to help an administrator or other authorized user to reconcile lostmessages, account for latency in messages as they move throughout anetwork, and any other suitable reconciliation process. In someexamples, the reconciliation engine 912 generates a list of nodes thatneed to be reconciled. For example, some nodes may not be transferringinformation (e.g., messages). This list can be sorted and prioritizedbased on message type, date, location, application, etc. In this manner,an authorized user will be informed as to which nodes need the mostimmediate attention and which nodes can be dealt with another day.

The notification engine 914 is configured to generate notificationsregarding the generation of unique message identifiers and tracking ofmessages. The anomaly detection engine 916 is configured to implementtechniques related to anomaly detection as described herein. Forexample, the anomaly detection engine 916 may be configured to estimatean expected quantity of messages for a particular node. The anomalydetection engine 916 may therefore be configured to access historicaldata representative of historical message transactions. This historicaldata can then be used by the anomaly detection engine 916 to generate abaseline of how many messages, of what type, originating from whichsystem and facility, and the like should be expected. The anomalydetection engine 916 may also be configured to monitor incomingmessages, compare the quantity (and other characteristics) to thebaseline, and determine whether the received/monitored messages areanomalous for a given time period.

The health monitor engine 918 is configured to monitor the health ofcomponents of the network. These components may include any suitabledevice of the network that is capable of sending and/or receiving data.In some examples, the health monitor engine 918 is configured to monitorthe health of a few major components of the network. For example, thetransformative integration engine 904 and other similar engines and/ordevices may be monitored by the health monitor engine 918. Monitoring acomponent by the health monitor engine 918 may include monitoringoperational characteristics of the component and alerting an authorizeduser when the operational characteristics exceed or drop below athreshold. The operational characteristics may relate to the messagesand may be monitoring using the unique message identifiers.

The interactive visualization engine 920 is configured to generate oneor more graphical diagrams that can be presented on user interfaces,such as interface 928. In some examples, the interactive visualizationengine 920 generates graphical diagrams based on movements of messageswithin a network. For example, a graphical diagram may include aplurality of nodes connected with a plurality of chords. The color andintensity of the nodes and the chords may be adjusted based on changestracked by one of the other engines of the transaction managementplatform 902. Any of the information generated by the transactionmanagement platform 902, including any output, may be provided to theinterface 928 and/or web application 926.

The transaction management platform 902 may also include a data servicesengine 924. The data services engine 924 may be configured to provideone or more services in a service-oriented architecture. For example,the data services engine 924 may enable other components to access tothe transaction management platform 902.

FIG. 10 illustrates a network 1000 in accordance with at least oneembodiment of the invention. The network 1000 includes the transactionmanagement platform 902, the transformative integration engine 904, thesending systems 908, the receiving systems 910, the web application 926,and the interface 928 previously discussed. In this figure, however,details about the architecture of the transaction management platform902 are illustrated in greater detail. The transaction management engine906(B), the reconciliation engine 912, the notification engine 914, theanomaly detection engine 916, the health monitor engine 918, theinteractive visualization engine 902, the transaction management storage922, the data services engine 924, and any other engine, service, ormodule of the transaction management platform may be distributed betweena data tier 1002, a service and business tier 1004, and a web tier 1006of the transaction management platform 902. In some examples, more orfewer tiers are included as may be appropriate to implementing themessage tracking techniques described herein. The data tier 1002 mayinclude one or more computer systems configured to manage the data thatis received, monitored, collected, and generated as part of implementingtechniques related to message tracking. The data tier 1002 may thereforeinclude a web server 1002(A), a data storage server 1002(B), and a fileserver 1002(C). The data tier 1002 may be configured to receive data inthe form of messages from the sending systems 908 and the transformativeintegration engine 904. Within the data tier 1002, the unique messageidentifiers are generated and associated with the messages.

From the data tier 1002 data flows to the service and business tier1004, and in some examples, to the receiving systems 910. The serviceand business tier 1004 includes one or more computer systems configuredto provide services via the interface 928 and to manage other aspects ofimplementing techniques relating to message tracking as describedherein. For example, within the service and business tier 1004 mayreside the software and/or hardware configured to perform anomalydetection. As illustrated, the service and business tier 1004 mayinclude a web server 1004(A), a data storage server 1004(B), and ageneric server 1004(C). From the service and business tier 1004, thedata, including indications (e.g., unique message identifiers), isprovided to the web tier 1006. The web tier 1006 may include a webserver 1006(A) and may be configured to provide access to at least aportion of the data generated within the transaction managementplatform. In particular, the web tier 1006 may be accessed via the webapplication 926.

Turning now to FIG. 11, in FIG. 11 is illustrated table 1100. The table1100 may be configured to include a record for each message that isreceived by the transaction management platform 902. Thus, the table1100 may include a plurality of rows and columns. The table 1100includes a time created column 1104, a source application column 1106, afacility column 1108, a message type column 1110, a message controlidentification column 1112, and tracking columns 1114, and 1116. Thedata in the time created column 1104 indicates a time that each messagewas created. The data in the source application column 1106 indicatesthe application from which each message originated. The data in thefacility column 1108 indicates a facility where each message wascreated. The data in the message type column 1110 indicates a messagetype of each message. The messages type may include any suitable messagetype used for transferring data. For example, the message types may bemedical record, medical document, radiology orders, pharmacy orders, labresults, home medications, emergency room documents, observationresults, patient problems, admissions/discharges, nursing documents,electronic medication, and any other suitable message type. The data inthe message control identification column 1112 defines the source,purpose, destination, and certain syntax specifics like delimiters(separator characters) and character sets for each message. The data inthe tracking columns 1114, 1116 are used to track the movements of themessages. For example, as each row corresponds to one message (or groupof messages) that has been received and recorded by the transactionmanagement platform 902, the entry (i.e., “Y”) in the tracking column1114 for a first row 1102 indicates that a first message was identifiedat the source node (e.g., “@Src”). Similarly, at the tracking column1116 and the first row 1102 there is no entry. This may indicate thatthe first message has not made it to the node identified by “CL,” whichmay be the next node after the source node. The column entries withinthe row 1102 may therefore correspond to the first message. Any or allof the column entries within the box 1102 may be found or added to theheader of the first message. The table 1100 may include more columnsthan are illustrated. For example, for a message that is required to gothrough many different nodes to reach its destination there may be moretracking columns to account for the additional nodes.

The column entries in the source application column 1106, the facilitycolumn 1108, the message type column 1110, and the message controlidentification column 1112 may be concatenated together to create aunique message identifier for the first message. In some examples, otherinformation is used to generate unique message identifiers. In someexamples, the unique message identifier is generated and included in thetable 1100, which is then saved. For example, for the first message(shown in the first row 1102), the unique message identifier maycomprise the concatenation of the entries from the columns discussedabove. The table 1100 may therefore include unique message identifiersfor more than one message.

Turning next to FIG. 12, in FIG. 12 is illustrated a user interface1200. FIGS. 11-19 illustrate other user interfaces in accordance withother embodiments. The user interface 1200 is an example of a userinterface that may be used to view the message tracking information asdescribed herein. For example, the interface 1200 may be accessible viaa web application on a user device. The user interface 1200 includessuitable functionality to enable a user to interact with the messagetracking information that will be provided on the user interface 1200.For example, the user interface 1200 includes a search bar 1202 and atime indicator 1204. The search bar 1202 enables a user to search forparticular message types, nodes, messages, and the like. While the timeindicator 1204 indicates a time period under consideration, which isrelated to what is presented on the user interface 1200. The timeindicator 1204 also acts as a bread crumb indicator to indicate levelsof granularity and the path that the user has taken within the userinterface 1200. The user interface 1200 may also be user configurable.The user interface 1200 includes a graphical diagram 1206. The graphicaldiagram 1206 includes a graphical representation of nodes of and flow ofmessages within a network. The graphical diagram 1206 may be generatedby the transaction management platform 902 in accordance with techniquesdescribed herein. Clicking on any of the nodes reveals a finer orcoarser level of detail.

The graphical diagram 1206 includes regional nodes 1208 and message typenodes 1210. The individual regional nodes 1208 are connected toindividual message type nodes 1210 via one or more chords 1212. Theregional nodes 1208 are sized relative to each other and, in thisexample, depend on the relative volume of messages processed by eachregional node, which may be a data center. For example, the regionalnode “FW” appears larger than the regional node “OR.” This may bebecause the FW region sent, provided, or otherwise transferred moremessages than in the OR region. Similarly, the message type nodes 1210are sized relative to each other and, in this example, depend on therelative volume of messages for each message type. The chords 1212 arealso sized relative to the number and type of messages for each region.For example, of all messages that originated the OR region, the largestnumber were “NUR” messages. Thus, the thickness of the chord between theOR data center and the NUR message type node is the thickest. Asdiscussed herein, the number of the regional nodes 1208 and the numberof the message type nodes 1210 is not fixed and may be adjusteddepending on the underlying messages, filters, and other dataorganization measures.

The graphical diagram 1206 also includes popup 1214. The popup 1214 maybe generated in response to a user selecting the “NA” regional node. Theinformation provided in the popup 1214 may be helpful to the user tounderstand how messages are flowing in the data center represented bythe NA regional node. The popup window 1214 illustrates the total volumeof messages for NA (“43,734”), the percentage of expected messages(“125.9%”), the number of connections represented by this regional node(“499”), and other relevant information. In some examples, otherinformation is presented. The information provided in the popup 1214 maybe dynamically updated by the transaction management platform 902.Clicking on “anomalies” 1216 adjusts the graphical diagram 1206 todisplay a tabular view of message volume and other details about themessages represented in the graphical diagram 1206 prior to clicking theanomalies 1216.

FIG. 13 illustrates a user interface 1300. The user interface 1300 is anexample of the user interface 1200. The user interface 1300 includes agraphical diagram 1302. The graphical diagram 1302 is configured todisplay message data flow by message type. The graphical diagram 1302includes a regional node 1304, facility nodes 1306, and message typenodes 1316 in a finer grain of detail than the graphical diagram 1202.This finer grain of detail is represented by the inclusion of thefacility nodes 1306. The facility nodes 1306 may represent individualfacilities within the region NA represented by the regional node 1304.Each facility represented by the facility nodes 1306 may include one ormore devices accessing one or more applications which generate themessages represented in the graphical diagram 1302. In some examples,the techniques described herein may be used to display geographic viewsof message data flow. Such views may enable identification ofproblematic geographic areas. For example, were a data center thatserves a geographic region, such a view would illustrate consequences(e.g., messages being backed up or held in caches, being negativelyacknowledged, returned undeliverable, and other similar consequences).

The graphical diagram 1302 also includes chords 1308 connecting theregional node 1304, the facility nodes 1306, and the message types nodes1316. In this example, the graphical diagram 1302 includes an anomalydetection overlay, indicated by the different chord fills. A largevariety of overlays are available in order to tailor the display of themessage tracking information on the graphical diagram 1302. Overlays orlayers may be used to graphically highlight or emphasize certainelements of the message tracking information. For example, chord 1310 isillustrated as having a different fill than chords, 1312 and 1314. Thismay be because, based on the total volume of messages within the datacenter represented by regional node 1304, the messages flowing from theOKA facility are lower than expected. This may indicate an anomaly.Similarly for the chord 1312, the color or shading of the chord 1312 mayindicate that the volume of message type HMED flowing out of the OKAfacility is lower than expected, higher than expected, or falling withinor without some other threshold. For example, a chord colored purple mayindicate that the message volume is higher than expected for the timeperiod under analysis (illustrated by time indicator 1318), a chordcolored red may indicate that no messages were received, a chord coloredyellow may indicate that the volume of messages is lower than expected,and a chord colored blue or no color may indicate that the volume ofmessages is within a range of what is expected. The range of expectedvolume may be determined by analyzing historical message flows andstatistically analyzing the historical data flows to arrive at anexpected data flow for region, facility, message type, or for otherparameters.

FIG. 14 illustrates a user interface 1400. The user interface 1400 is anexample of the user interface 1200. The user interface 1400 includes agraphical diagram 1402. The graphical diagram 1402 is configured todisplay message data flow by message type. The graphical diagram 1402particularly illustrates menu 1404. The menu 1404 is accessed byclicking menu button 1406. Accessing the menu 1404 enables a user toaccess many of the available layers, filters, overlays, and the like.These different options provide different methods of presenting messagetracking information. For example, the menu 1404 includes items such asreconciliation history, reconciliation, data flow, component flow,message history, message quality original sources, TLM feeds, excludedfacilities, issue list, BizTalk health, user admin, and server info.Clicking any one of the items will navigate to a different screen and/ororganize the message tracking information differently. For example, box1408 indicates that the current item selected is data flow. Thus, thegraphical diagram 1402 presents message tracking information organizedby the data flow item.

FIG. 15 illustrates a user interface 1500. The user interface 1500 is anexample of the user interface 1200. The user interface 1500 includes agraphical diagram 1502. The graphical diagram 1502 is configured todisplay message data flow by message type. The graphical diagram 1502particularly illustrates filter menu 1504. The filter menu 1504 isaccessed by clicking filter button 1506. The filter button 1506 causesthe filter menu 1504 to open. The filter menu 1504 includes a variety offilter options available for filtering the message tracking information.For example, the time period under consideration may be adjusted byadjusting the “date and time” filter option. Similarly, the “duration”option adjusts the amount of time corresponding to the time period.Other filter options in the filter menu 1504 include, for example,source and application option, data center option, network option,facility option, and message type option. The filters can be reset usingthe “reset” button.

FIG. 16 illustrates a user interface 1600. The user interface 1600 is anexample of the user interface 1200. The user interface 1600 includes agraphical diagram 1602. The graphical diagram 1602 is configured todisplay message component data flow by message type. Thus, in thisexample, a user has selected the “component flow” item from the menu1404. The graphical diagram 1602 includes source nodes 1604,intermediate nodes 1606(A), 1606(B), and destination nodes 1608.Similarly as before, each of the source nodes 1604, the intermediatenodes 1606(A), 1606(B), and the destination nodes 1608 may be clicked toprovide more or less granularity.

The intermediate node 1606(B) is illustrated differently than the othernodes. In some examples, this may indicate the health of theintermediate node 1606(B). In this example, the intermediate node1606(B) is an integration engine, such as the transformative integrationengine 102. Because the intermediate node 1606(B) is highlighted orformatted different than the other nodes, the health of the intermediatenode 1606(B) may have fallen below some threshold, confidence level,some combination of a threshold and confidence level, or any othersuitable method for determining when to illustrate a health concern. Insome examples, the health of the intermediate node 1606(B) is determinedby monitoring one or more operational characteristics corresponding tothe component represented by the intermediate node 1606(B). Clicking onthe intermediate node 1606(B) may load a different graphical diagram ortable (e.g., a “health page”) to present which operationalcharacteristics have fallen below which thresholds. This information maybe desirable for responding to health concerns relating to the componentrepresented by the intermediate node 1606(B). Hovering over any of thechords causes a popup to appear, e.g., a popup 1610. The popup 1610indicates the number of messages and where they most recently came from.In this example, the number of messages for the NUR message type betweenthe intermediate node 1606(A) and the intermediate node 1606(B) is41,984 and the most recent node is the intermediate node 1606(A), i.e.,“Cloverleaf.” In some examples, the health of the is updated in nearreal-time (e.g., every 5-10 minutes).

The source nodes 1604 are examples of sending systems discussed herein.In some examples, the source nodes 1604 are configured to manage certainaspects of clinical data. The destination nodes are examples of thereceiving systems discussed herein. In some examples, the source nodes1604 are configured to store messages transferred within the network.Using the techniques described herein, a user is enabled to view how themessages are moving from the source nodes 1604 to the destination nodes1608.

FIG. 17 illustrates a user interface 1700. The user interface 1700 is anexample of the user interface 1200. The user interface 1700 includes agraphical diagram 1702. The graphical diagram 1702 is configured todisplay message data flow for reconciliation purposes. Use of thegraphical diagram 1702 for message reconciliation enables a user toidentify potential issues with message delivery. The graphical diagram1702 can be organized by message type, source, data center, network, orfacility. Similarly, the data can be presented based on errors, paths,latency, or all data. In this example, the graphical diagram 1702 isorganized by message type because “msg type” option 1704 has beenselected. The graphical diagram 1702 includes messages 1706 organized bymessage type. The graphical diagram 1702 also includes quantities ofmessages 1708 and status of messages area 1710. The status of messagesarea 1710 indicates, by way of adjusted formatting, the number ofmessages which reached their destinations, which were not reconciled,which were negatively acknowledged, and those for which reconciliationfrom the source is still unknown. Thus, in some examples, the graphicaldiagram 1702 illustrates different reconciliation statuses for messagesin the network. In some examples, the bars in the message area 1710 arecolored differently depending on the status of the messages. Forexample, green may indicate those messages that made it to theirdestination, yellow may indicate those messages for which there is nostatus, red may indicate those messages that were negativelyacknowledged or unreconciled, and gray may indicate those messages thatare ignored for one reason or another.

Hovering over the bars in the status of messages area 1710 revealsadditional details about the messages represented by the bars. Forexample, a popup 1712 indicates details about certain messages that werenot reconciled to their destination. The system may determine that amessage is reconciled to a destination after the transaction managementplatform 902 receives an indication from the destination node that themessage was received. In some examples, the graphical diagram 1702 maybe altered by a user clicking on a button in a filter menu 1712. Forexample, the “path” filter is currently being applied, but selecting“errors,” “latency,” or “all” may bring up different message trackingdata presented in a different manner. This different manner may includedifferent formatting. In some examples, a user can click on any of thebars in the graphical diagram 1702 in order to see more details aboutthe messages. For example, the user can click on the bar correspondingto the popup 1712 to see the actual 45 messages that are currentlyunreconciled. From this location, the user can also generate a case forresolving the problem, download the messages, adjust the statuses, andreplay the messages to see where the problem may be located.

FIG. 18 illustrates a user interface 1800. The user interface 1800 is anexample of the user interface 1200. The user interface 1800 includes agraphical diagram 1802. The graphical diagram 1802 is configured todisplay message data flow quality by facility. In particular, thegraphical diagram 1802 depicts a graphical representation of thequantity of messages and the status of messages compared to quantitiesand statuses of other messages. Thus, the graphical diagram 1802includes one or more major shapes 1804. In this example, the one or moremajor shapes 1804 are the larger rectangles in the graphical diagram1802, which include smaller rectangles (e.g., minor shapes) within. Forexample, the rectangle with the term “Home Medications” is a majorshape, while located within this major shape is located one or moreminor shapes 1806. The other major shapes 1804 also include other minorshapes. In this example, each of the major shapes 1804 corresponds to atype of message. The size of the minor shapes 1806 is proportional tothe gross number of errors corresponding to the messages of theparticular type. The formatting (e.g., color, shading, fill, etc.) ofeach of the minor shapes (e.g., the minor shapes 1806 and others in themajor shapes 1804) represents the percentage of errors compared to thetotal number of messages. In this example, the minor shapes 1806 and theothers in the major shapes 1804 correspond to facilities within thenetwork. A user can click on any one of the major shapes 1804 and willbe navigated to a zoomed-in view of the major shape, as illustrated inFIG. 19.

In some examples, the message tracking information may be presenteddifferently in the graphical diagram 1802 by selecting “naks,” “moderatelatency,” or “severe latency.” Each of these selections may act as afilter to adjust the data that is presented. For example, selecting oneof the “latency” selections may adjust the graphical diagram 1802 todisplay the data based on latency. In some examples, the formatting inthe latency selection may correspond to one of the following: formessages that took less than 3 minutes, a first color, shade, or fillmay be used; for messages that took greater than three minutes, but lessthan four hours, a second color, shade, or fill may be used; formessages that took greater than four hours, a third color, shade, orfill may be used; and for all other messages, a fourth color, shade, orfill may be used. In this manner, the graphical diagram 1802 may beorganized according to latency and present data in a prioritizedfashion. The data is prioritized because the user can immediately seenot only the gross number of messages (represented by size of theshapes), but also the intensity of the problem (i.e., the percentage ofthe whole) represented by the formatting of the shapes. In someexamples, the minor shapes 1806 (and other minor shapes) may fill theentirety of the major shapes 1804. In some examples, the minor shapes1806 and/or the major shapes 1804 are rectangles, squares, polygons,circles, and any other suitable shape.

FIG. 19 illustrates a user interface 1900. The user interface 1900 is anexample of the user interface 1200. The user interface 1900 includes agraphical diagram 1902. The graphical diagram 1902 is configured todisplay message data flow quality by facility. In particular, thegraphical diagram 1902 depicts a graphical representation of thequantity of messages of a single type and the status of those messagesfor multiple facilities. In some examples, the graphical diagram 1902 isgenerated as a result of a user clicking on the major shape entitled“Medical Record” shown in FIG. 18. Thus, the graphical diagram 1902includes one or more minor shapes 1904 arranged in a chart format. Thesize of the minor shapes 1904 is proportional to the gross number oferrors for the medical record type of message which correspond to eachof the different facilities (e.g., COCVW, COCLE, etc.) in the network.The formatting (e.g., color, shading, fill, etc.) of each of the minorshapes 1904 represents the percentage of errors compared to the totalnumber of messages for the particular minor shape. In this manner, boththe number of messages and the intensity of the problem are highlighted.Thus, a popup 1906 illustrates that for the medical facility named“Medical Record (MR) at Lawnwood Regional Medical Center (COCVW),” 14messages have been received, 3 are unreconciled, which constitutes 21.4%of the total messages of the message type medical record for thisfacility. Similar to the graphical diagram 1802, the graphical diagram1902 can be adjusted to display message tracking information based onnegatively acknowledged messages (i.e., “naks”), “moderate latency,” or“severe latency.” In some examples, the diagram 1902 may be adjusted todisplay similar data in a data grid format.

FIG. 20 illustrates a flowchart of a process 2000 for tracking movementof messages within a network according to an embodiment of theinvention. Some or all of the process 2000 (or any other processesdescribed herein, or variations and/or combinations thereof) may beperformed under the control of one or more computer systems configuredwith executable instructions and may be implemented as code (e.g.,executable instructions, one or more computer programs or one or moreapplications) executing collectively on one or more processors, byhardware or combinations thereof. The code may be stored on acomputer-readable storage medium, for example, in the form of a computerprogram comprising a plurality of instructions executable by one or moreprocessors. The computer-readable storage medium may be non-transitory.The process 2000 begins at block 2002 by identifying one or moremessages. In some examples, each of the messages is representative of asingle transaction within the network. Each of the messages mayoriginate from a respective source node of the network.

At 2004, the process 2000 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2006, the process 2000 stores an indication of each of the one ormore messages in a data store. In some examples, the indication of eachof the one or more messages is associated with the corresponding uniquemessage identifiers. Thus, in some examples, the unique messageidentifier is stored in a data store in a tabular format. For example,the table may include a source application identifier, a source facilityidentifier, a message type identifier, a message control identifier, andany other suitable entry for tracking the movement of the message. Insome examples, once a message is received by a node of the network, thetable is updated to indicate as such. In this manner, the movement ofthe message is tracked throughout the network.

At 2008, the process 2000 alters each of the one or more messages toinclude the corresponding unique message identifiers. In some examples,altering the messages may include adding the unique message identifierto the headers of the messages. In some examples, the messages are inthe HL7 format or any other suitable format.

At 2010, the process 2000 tracks movements of a message of the one ormore messages within the network. In some examples, the block 2010 isperformed by sub-process 2012. Thus, at 2014, the sub-process 2012receives an indication that the message was received by a node of thenetwork. In some examples, the indication is received by the transactionmanagement platform. At 2016, the sub-process 2012 indicates, within thedata store and based at least in part on a unique message identifiercorresponding to the message, that the message was received by the nodeof the network. At 2018, the sub-process 2012 updates a statusassociated with the message based at least in part on the indication. Insome examples, the status may indicate that the message was received,negatively acknowledged, not received, or unknown.

FIG. 21 illustrates a flowchart of a process 2100 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2100 begins at block 2102 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2104, the process 2100 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2106, the process 2100 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2108, the process 2100 determines a first group of nodes to includein a graphical diagram, the first group of nodes selected from theplurality of nodes of the network. In some examples, the first group ofnodes may include geographic nodes of the network and message typenodes. Thus, in some examples, the first group of nodes includes nodesthat represent different aspects of the network. Any suitablecombination of nodes, representing varying aspects of the network, maybe included in the first group of nodes.

At 2110, the process 2100 determines a first group of chords to includein the graphical diagram, the first group of chords providing graphicaldepictions of message flow between at least a portion of the first groupof nodes. In some examples, the width of the chords correspond to thenumber of messages associated with the two nodes. For example, the widthmay represent the number of messages flowing between the two nodes.Additionally, in some examples, the width may represent the number ofmessages of a particular message type that have been processed by one ofthe nodes. In this manner, the chords may represent different aspects ofdata flow.

At 2112, the process 2100 provides the graphical diagram including thefirst group of nodes and the first group of chords for presentation on auser interface. In some examples, the graphical diagram is configurableto depict movements of the portion of the one or more messages among thefirst group of nodes.

FIG. 22 illustrates a flowchart of a process 2200 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2200 begins at block 2202 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2204, the process 2200 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2206, the process 2200 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2208, the process 2200 assigns a reconciliation status to each of theone or more messages assigning a reconciliation status to each of theone or more messages. In some examples, the reconciliation statuscorresponds to whether each of the one or more messages were received byrespective destination nodes. In some examples, the reconciliationstatus may include whether a message was successfully received,negatively acknowledged, not received, or unknown. In some examples, thereconciliation status may be generated dynamically in response to userinput.

At 2210, the process 2200 provides a graphical diagram including thereconciliation status for each of the one or more messages forpresentation on a user interface. In some examples, the graphicaldiagram includes a graph indicating the statuses for groups of messagesorganized by message type, facility, or otherwise.

FIG. 23 illustrates a flowchart of a process 2300 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2300 begins at block 2302 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2304, the process 2300 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2306, the process 2300 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2308, the process 2300 provides providing at least a portion of thelatency information for use in a compliance report. In some examples,the compliance report in provided to a reporting agency, stakeholders,operators, or other entities and/or individuals. Preparation of thecompliance report may include the collection of statistics relating tothe care and service offered at a medical facility. For example, thecompliance report may indicate the timeliness of discharges of patients.By analyzing the movement of messages within the network, the timelinessof patient discharge may be determined. In some examples, this mayinclude comparing a time of a first message indicating an action priorto discharge with a time of a second message indicating an action afterand/or at discharge. In some examples, the compliance report may be atleast partially auto-generated using the techniques described herein. Insome examples, the compliance report may be required by a service levelagreement.

FIG. 24 illustrates a flowchart of a process 2400 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2400 begins at block 2402 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2404, the process 2400 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2406, the process 2400 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2408, the process 2400 determines a quantity of expected messages fora current time period. In some examples, the determination is based atleast in part on historical message data for a time period. In someexamples, the time period corresponds to the current time period. Insome examples, the time period is a period of time in the past which canbe used as a baseline for comparing with the current time period. Forexample, for the time period the historical message data may indicatethat a certain number of messages were received (e.g., 5,000). In someexamples, the historical message data indicates, for each node of thenetwork, the number of messages, the message types, the problemsassociated with the network at that time, the source application types,and any other suitable type of information that is tracked by thetransaction management platform. In some examples, the expected messagesare the same quantity of messages received in the time period. Thus, ifthe expected messages, in this example, may be 5,000.

At 2410, the process 2400 provides a graphical diagram for presentationon a user interface. In some examples, the graphical diagram includes arepresentation of movement of at least a portion of the one or moremessages within the network for the current time period. In someexamples, the portion of the one or more messages is presented in amanner including nodes and chords as described herein. In some examples,the portion of the one or more messages is presented in a mannerincluding sliding bar graphs.

At 2412, the process 2400 compares a quantity of received messages withthe quantity of expected messages to determine a comparison quantity ofmessages. In some examples, the comparison quantity of messages isdetermined by subtracting the received messages from the expectedmessages. In some examples, the comparison quantity of messages is usedto determine whether the quantity of received messages exceeds, goesbelow, or equals the quantity of expected messages.

At 2414, the process 2400 selectively highlights a portion of thegraphical diagram based at least in part on the comparison quantity ofmessages. In some examples, if the comparison quantity of messages orthe quantity of received messages exceeds a threshold corresponding tothe expected messages, nodes of the graphical diagram may be highlighteda first color. In some examples, if the comparison quantity of messagesor the quantity of received messages greatly exceeds a thresholdcorresponding to the expected messages, nodes of the graphical diagrammay be highlighted a second color. In some examples, if the comparisonquantity of messages or the quantity of received messages falls below athreshold corresponding to the expected messages, nodes of the graphicaldiagram may be highlighted a third color. In some examples, if thecomparison quantity of messages or the quantity of received messagesfalls very below a threshold corresponding to the expected messages,nodes of the graphical diagram may be highlighted a fourth color. Insome examples, if the comparison quantity of messages or the quantity ofreceived messages is undeterminable, nodes of the graphical diagram maybe highlighted a fifth color. In some examples, chords of the graphicaldiagram are also selectively highlighted. In some examples, thehighlighting of the portion of the graphical diagram includes changingthe color, shading, fill, or other formatting of nodes, chords, graphs,text, and the like in the graphical diagram.

FIG. 25 illustrates a flowchart of a process 2500 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2500 begins at block 2502 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2504, the process 2500 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2506, the process 2500 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2508, the process 2500 identifies one or more operationalcharacteristics of a network component to which some of the one or moremessages were addressed. In some examples, identifying is based at leastin part on the movements of the portion of the one or more messages.

At 2510, the process 2500 provides a graphical diagram for presentationon a user interface. In some examples, the graphical diagram depictshealth of the network component in terms of the one or more operationalcharacteristics. In some examples, the health of the network componentis represented by a change in a graphical characteristic of a node thatrepresents the network component. In some examples, the health of thenetwork component is represented in a table or graph. In some examples,the table or graph includes details describing how the message trackingdata indicates the health of the component.

FIG. 26 illustrates a flowchart of a process 2600 for providinginteractive visualization of message tracking information according toan embodiment of the invention. The process 2600 begins at block 2602 byidentifying one or more messages. In some examples, each of the messagesis representative of a single transaction within the network. Each ofthe messages may originate from a respective source node of the network.

At 2604, the process 2600 generates unique message identifiers for eachof the one or more messages. In some examples, each unique messageidentifier may be generated based at least in part on at least one of asource application identifier, a source facility identifier, a messagetype identifier, or a message control identifier. In some examples, theunique message identifier is a concatenation of the source applicationidentifier, the source facility identifier, the message type identifier,and the message control identifier. In some examples, the unique messageidentifier represents an underlying message and is used to track themovement of the message as it moves throughout the network. In someexamples, the unique message identifier represents a pointer that pointsto the message and enables selection and access of the message whereverit may be stored.

At 2606, the process 2600 tracks, using the unique message identifiers,movements of a portion of the one or more messages among the pluralityof nodes of the network. In some examples, tracking the movements of theportion of the one or more messages includes receiving updates fromnodes that receive the messages. In some examples, the nodes of thenetwork include computer systems, components, devices, geographicregions, message types, facilities, applications, and any other suitablerepresentation of data flow that can be tracked.

At 2608, the process 2600 provides a graphical diagram for presentationon a user interface. In some examples, the graphical diagram includesone or more major shapes and one or more minor shapes. In some examples,the one or more major shapes each represent a message type of theportion of the one or more messages that has been tracked. In someexamples, the one or more minor shapes each represent a facility fromwhich the portion of the one or more messages previously originated. Insome examples, the one or more minor shapes are disposed within the oneor more major shapes. In some examples, the size of each of the one ormore major shapes is dependent on a quantity of messages correspondingto the message type of the respective major shape, and the size of eachof the one or more minor shapes is dependent on a quantity of messagescorresponding to the respective facility of the minor shape. In someexamples, the formatting (e.g., color, shading, fill, etc.) of each ofthe minor shapes represents the percentage of errors compared to thetotal number of messages for the particular minor shape. In this manner,both the number of messages and the intensity of the problem arehighlighted.

Specific details are given in the above description to provide athorough understanding of the embodiments. However, it is understoodthat the embodiments may be practiced without these specific details.For example, circuits may be shown in block diagrams in order not toobscure the embodiments in unnecessary detail. In other instances,well-known circuits, processes, algorithms, structures, and techniquesmay be shown without unnecessary detail in order to avoid obscuring theembodiments.

Implementation of the techniques, blocks, steps and means describedabove may be done in various ways. For example, these techniques,blocks, steps and means may be implemented in hardware, software, or acombination thereof. For a hardware implementation, the processing unitsmay be implemented within one or more application specific integratedcircuits (ASICs), digital signal processors (DSPs), digital signalprocessing devices (DSPDs), programmable logic devices (PLDs), fieldprogrammable gate arrays (FPGAs), processors, controllers,micro-controllers, microprocessors, other electronic units designed toperform the functions described above, and/or a combination thereof.

Also, it is noted that the embodiments may be described as a processwhich is depicted as a flowchart, a flow diagram, a swim diagram, a dataflow diagram, a structure diagram, or a block diagram. Although adepiction may describe the operations as a sequential process, many ofthe operations can be performed in parallel or concurrently. Inaddition, the order of the operations may be re-arranged. A process isterminated when its operations are completed, but could have additionalsteps not included in the figure. A process may correspond to a method,a function, a procedure, a subroutine, a subprogram, etc. When a processcorresponds to a function, its termination corresponds to a return ofthe function to the calling function or the main function.

Furthermore, embodiments may be implemented by hardware, software,scripting languages, firmware, middleware, microcode, hardwaredescription languages, and/or any combination thereof. When implementedin software, firmware, middleware, scripting language, and/or microcode,the program code or code segments to perform the necessary tasks may bestored in a machine readable medium such as a storage medium. A codesegment or machine-executable instruction may represent a procedure, afunction, a subprogram, a program, a routine, a subroutine, a module, asoftware package, a script, a class, or any combination of instructions,data structures, and/or program statements. A code segment may becoupled to another code segment or a hardware circuit by passing and/orreceiving information, data, arguments, parameters, and/or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted via any suitable means including memorysharing, message passing, token passing, network transmission, etc.

For a firmware and/or software implementation, the methodologies may beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. Any machine-readable mediumtangibly embodying instructions may be used in implementing themethodologies described herein. For example, software codes may bestored in a memory. Memory may be implemented within the processor orexternal to the processor. As used herein the term “memory” refers toany type of long term, short term, volatile, nonvolatile, or otherstorage medium and is not to be limited to any particular type of memoryor number of memories, or type of media upon which memory is stored.

Moreover, as disclosed herein, the term “storage medium” may representone or more memories for storing data, including read only memory (ROM),random access memory (RAM), magnetic RAM, core memory, magnetic diskstorage mediums, optical storage mediums, flash memory devices and/orother machine readable mediums for storing information. The term“machine-readable medium” includes, but is not limited to portable orfixed storage devices, optical storage devices, and/or various otherstorage mediums capable of storing that contain or carry instruction(s)and/or data.

While the principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure.

What is claimed is:
 1. A computer-implemented method, comprising:identifying, by a computer system, a plurality of medical messages, eachmedical message of the plurality of medical messages beingrepresentative of a single transaction within a medical network andoriginating from a respective network node of a plurality of networknodes of the medical network; tracking, by the computer system and basedin part on a unique message identifier for each of the plurality ofmedical messages, movements of the plurality of medical messages withrespect to the plurality of network nodes of the medical network;determining, by the computer system and based on tracking the movementsof the plurality of medical messages, message tracking information thatrepresents movements of the plurality of medical messages with respectto the plurality of network nodes of the medical network; and providing,by the computer system and based in part on the message trackinginformation, a first graphical diagram for presentation on a userinterface, the first graphical diagram graphically depicting a pluralityof variably-sized chords extending between a plurality of data nodes,each data node corresponding to a property of the plurality of medicalmessages.
 2. The computer-implemented method of claim 1, wherein: theplurality of data nodes represent a portion of the plurality of networknodes; and a width of each variably-sized chord depends on a quantity ofmedical messages flowing between the network nodes represented by theplurality of data nodes.
 3. The computer-implemented method of claim 1,wherein: the plurality of data nodes represent at least a first networknode and a message type of a portion of the plurality of medicalmessages: and a width of each variably-sized chord depends on a quantityof medical messages of the message type that flow into or out of thefirst network node.
 4. The computer-implemented method of claim 1,wherein the plurality of data nodes represent at least one of a regionalnetwork node, a message type, a facility, or an application.
 5. Thecomputer-implemented method of claim 1, further comprising generatingthe unique message identifiers for each of the plurality of medicalmessages, each unique message identifier of the unique messageidentifiers generated based at least in part on at least one of a sourceapplication identifier, a source facility identifier, a message typeidentifier, or a message control identifier.
 6. The computer-implementedmethod of claim 1, wherein tracking the movements of the plurality ofmedical messages comprises: confirming receipt of a first communicationfrom a first network node of the plurality of network nodes, the firstcommunication comprising a first unique message identifier associatedwith a first medical message of the plurality of medical messages; andconfirming receipt of a second communication from a second network nodeof the plurality of network nodes, the second communication comprisingthe first unique message identifier associated with the first medicalmessage.
 7. The computer-implemented method of claim 1, furthercomprising: generating a second graphical diagram based in part onupdated message tracking information; and providing the second graphicaldiagram for presentation on the user interface, the second graphicaldiagram graphically depicting a different plurality of variably-sizedchords extending between the plurality of data nodes.
 8. Thecomputer-implemented method of claim 1, further comprising: receiving arequest to filter the message tracking information based on a filter;and updating the first graphical diagram based in part on the filter. 9.The computer-implemented method of claim 8, wherein: the request tofilter is received via the user interface; and the filter comprises atleast one of a message type, an application type, a source applicationtype, a target application type, a source facility, a target facility,or a data center.
 10. One or more non-transitory computer-readable mediacomprising computer-executable instructions that, when executed by oneor more computer systems, cause the one or more computer system toperform operations comprising: identifying a plurality of medicalmessages, each medical message of the plurality of medical messagesbeing representative of a single transaction within a medical networkand originating from a respective network node of a plurality of networknodes of the medical network; tracking, based in part on a uniquemessage identifier for each of the plurality of medical messages,movements of the plurality of medical messages with respect to theplurality of network nodes of the medical network; determining, based ontracking the movements of the plurality of medical messages, messagetracking information that represents movements of the plurality ofmedical messages with respect to the plurality of network nodes of themedical network; and providing, based in part on the message trackinginformation, a first graphical diagram for presentation on a userinterface, the first graphical diagram graphically depicting a pluralityof variably-sized chords extending between a plurality of data nodes,each data node corresponding to a property of the plurality of medicalmessages.
 11. The one or more non-transitory computer-readable media ofclaim 10, wherein: the plurality of data nodes represent a portion ofthe plurality of network nodes; and a width of each variably-sized chorddepends on a quantity of medical messages flowing between the networknodes represented by the plurality of data nodes.
 12. The one or morenon-transitory computer-readable media of claim of claim 10, wherein:the plurality of data nodes represent at least a first network node anda message type of a portion of the plurality of medical messages; and awidth of each variably-sized chord depends on a quantity of medicalmessages of the message type that flow into or out of the first networknode.
 13. The one or more non-transitory computer-readable media ofclaim 10, wherein the plurality of data nodes represent at least one ofa regional network node, a message type, a facility, or an application.14. The one or more non-transitory computer-readable media of claim 10,wherein the operations further comprise generating the unique messageidentifiers for each of the plurality of medical messages, each uniquemessage identifier of the unique message identifiers generated based atleast in part on at least one of a source application identifier, asource facility identifier, a message type identifier, or a messagecontrol identifier.
 15. The one or more non-transitory computer-readablemedia of claim 10, wherein tracking the movements of the plurality ofmedical messages comprises: confirming receipt of a first communicationfrom a first network node of the plurality of network nodes, the firstcommunication comprising a first unique message identifier associatedwith a first medical message of the plurality of medical messages; andconfirming receipt of a second communication from a second network nodeof the plurality of network nodes, the second communication comprisingthe first unique message identifier associated with the first medicalmessage.
 16. A system, comprising: a memory configured to storecomputer-executable instructions; and a processor configured to accessthe memory and execute the computer-executable instructions to at least:identify a plurality of medical messages, each medical message of theplurality of medical messages being representative of a singletransaction within a medical network and originating from a respectivenetwork node of a plurality of network nodes of the medical network;track, based in part on a unique message identifier for each of theplurality of medical messages, movements of the plurality of medicalmessages with respect to the plurality of network nodes of the medicalnetwork; determine based on tracking the movements of the plurality ofmedical messages, message tracking information that represents movementsof the plurality of medical messages with respect to the plurality ofnetwork nodes of the medical network; and provide, based in part on themessage tracking information, a first graphical diagram for presentationon a user interface, the first graphical diagram graphically depicting aplurality of variably-sized chords extending between a plurality of datanodes, each data node corresponding to a property of the plurality ofmedical messages.
 17. The system of claim 16, wherein thecomputer-executable instructions further include instructions to atleast: generate a second graphical diagram based in part on updatedmessage tracking information; and provide the second graphical diagramfor presentation on the user interface, the second graphical diagramgraphically depicting a different plurality of variably-sized chordsextending between the plurality of data nodes.
 18. The system of claim16, wherein the computer-executable instructions further includeinstructions to at least: receive a request to filter the messagetracking information based on a filter; and update the first graphicaldiagram based in part on the filter.
 19. The system of claim 18,wherein: the request to filter is received via the user interface; andthe filter comprises at least one of a message type, an applicationtype, a source application type, a target application type, a sourcefacility, a target facility, or a data center.
 20. The system of claim16, wherein: the plurality of data nodes represent a portion of theplurality of network nodes; and a width of each variably-sized chorddepends on a quantity of medical messages flowing between the networknodes represented by the plurality of data nodes.